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Preface 


On December 12-13, 1990, about 75 managers, developers and operations 
experts from NASA and industry met at the Goddard Space Flight Center 
in an interactive forum to suggest ideas and discuss issues pertaining to 
the Space Network Control (SNC) environment of the late 1990s. The goals 
of the SNC Conference on Resource Allocation Concepts and Approaches 
were to survey existing resource allocation concepts and approaches, to 
identify solutions applicable to the SN and to identify fruitful avenues of 
investigation in support of SNC development. Participants heard from 
experienced speakers on topics related to the three sessions: 

1. Concepts for Space Network Resource Allocation 

2. SNC and User POCC Human-Computer Interface Concepts 

3. Resource Allocation Tools, Technology, and Algorithms 

Working group sessions followed each group of presentations to discuss 
recommendations for the future SNC. This document is a report on the 
conference, incorporating comments from the presentations and 
discussion notes. 

This conference would not have been possible without contributions from 
many people. I would like to thank the invited speakers whose 
presentations provided insight into the Space Network scheduling domain 
as well as visions for future directions. I also want to thank Dolly 
Perkins/510, Pepper Hartley/522, Phil Liebrecht/530, Candace Carlisle/532, 
BJ Hayden/534, Vern Hall/534, and Doug McNulty/STel who contributed as 
group leaders, and Beth Antonopulos/511, Tom Barlett/514, Eric 
Richmond/522, Nancy Goodman/522, Lisa Karr/STel, Nadine Happell/STel, 
Ken Johnson/STel, and Brian Dealy/CSC who were group reporters. Larry 
Hull and Nancy Goodman, both from Goddard Code 522, were especially 
helpful in program planning and identifying speakers; Lisa Karr and Doug 
McNulty of Stanford Telecom made significant contributions to the 
program planning and preparing the symposium facilities; Nadine 
Happell, also of Stanford Telecom, reviewed and edited these proceedings; 
and finally, Bill Watson, the Goddard SNC Program Manager, fully 
supported the concept and format for the conference. 

My sincere thanks goes to all of these individuals, as well as the many 
participants who contributed openly and freely to the discussion, which is 
in part reflected in these proceedings. 


Karen L. Moe 
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Executive Summary 

The Space Network Control (SNC) Conference on Resource Allocation 
Concepts and Approaches provided a beneficial forum for exchanging 
perspectives and ideas on the Mission Operations and Data Systems 
Directorate (MO&DSD) planning and scheduling environments. In the late 
1990s when the Advanced Tracking and Data Relay Satellite System 
(ATDRSS) is operational, Space Network (SN) services will be supported 
and controlled by the SNC. Goals for the SNC are to design a system 
capable of accommodating changes, to improve user satisfaction, and to 
improve the use and effectiveness of institutional systems. SNC challenges 
include dealing with existing operational issues, ones such as minimizing 
the impact of Shuttle launch slips, and determining the appropriate 
balance between manual and automated functions. But there are also new 
challenges, such as supporting demand access and interoperability with 
international data relay satellite networks. 

The conference goals were to survey existing resource allocation concepts 
and approaches, to identify solutions applicable to the SN, and to identify 
fruitful avenues of investigation in support of SNC development. About 75 
people participated, representing various levels of NASA and industry 
management, developers, and operations expertise in both the scheduler 
and service user domains. For two days, participants heard from 
experienced speakers on topics related to resource allocation concepts, 
interfaces and technology, and then participated in dynamic working group 
discussions to elicit recommendations for the future SNC. The following 
paragraphs condense and summarize several of the key recommendations 
from the conference. 

Management Roles 

For the ATDRSS era, providing a concise operations concept with 
unambiguous guidelines for operations is a top management responsibility. 
The MO&DSD should establish an intersystems engineering team to 
address end-to-end planning and scheduling issues. Systems to be 
included are the SN ground terminals at White Sands New Mexico, 
ATDRSS, the next generation NASA communications network (NASCOM 
ID, the Customer and Data Operations System (CDOS), and the user 
Payload Operations Control Centers (POCCs), as well as the SNC. A "help 
desk" for SN users is also recommended, which would provide advice 
during mission definition, as well as guidance during mission operations. 

The MO&DSD should specify the criteria for success in delivering SN 
services, determine and measure schedule quality parameters, and provide 
feedback to users (e.g., compare actual support vs support negotiated in the 
mission System Interface Requirements Document). Automatic online 
accounting features should be built into the SNC . Statistics on mission 
requests, schedule results, resource utilization, and timeliness of schedule 
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generation should be maintained to monitor trends, evaluate operations, 
and adjust scheduling goals and priorities. 

Qperations/Automation 

Based on experience in the current Network Control Center (NCC), both 
human interaction and some level of automation are necessary for 
successful and efficient SNC operations. The recommended approach is to 
provide automated tools that assist schedulers. Usability is measured by 
such factors as the time to train operators, and the system's ability to check 
inputs, to allow "undo" commands, and to provide the operator guidance. 

SN schedule generation is seen as a decision support process, but finding 
the appropriate level of automation is challenging. One recommendation is 
to design a system that initially allows humans to make decisions, and 
evolves into a more automated system. Operations personnel would 
identify routine decisions to delegate to machines as part of the process of 
designing algorithms to emulate human behavior. Another 
recommendation is to design a system with automated decision making, 
but provide full visibility into the entire process, allowing manual override 
by exception. 

The SNC definition should include system engineering approaches, such 
as modelling the current scheduling process objectives (not necessarily the 
specific procedures). Human factors analysis methodologies should be 
employed to identify those functions humans perform best vs functions best 
performed by machines. Existing industry standards and guidelines for 
human-computer interfaces should be applied, using tools such as NASA's 
Transportable Applications Executive, TAE+, to allow rapid prototyping 
and easy modification of displays. Both NCC and mission scheduler 
personnel should be involved throughout the SNC life cycle development to 
evaluate prototypes and verify requirements. Such involvement requires 
high level management commitments to allow operations personnel the 
time to participate. 

New SNC - User POCC Interface 

The current scheduling interface to the user POCC involves a stand-alone 
terminal dedicated to generating and transmitting specific SN service 
requests to the NCC. A challenging goal of the SNC is to engineer a new 
user POCC interface, accommodating a variety of user needs, as well as 
providing continued support to existing users. Scheduling SN services is a 
key part of a larger scheduling requirement for the POCC. A hardware 
independent toolset composed of modular, reusable software components 
should be provided as an optional scheduling aid, allowing user POCCs to 
integrate SN scheduling tools with their mission unique systems. 

The SN scheduling process should be compatible with user mission goals, 
but different classes of missions have different schedule drivers. The 
scheduling interface needs to accommodate both high and low priority 
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users, users who have scheduling flexibility and those who don't, and users 
with different scheduling timelines. A user scheduling timeline is the 
most natural time frame for planning and scheduling activities. User 
timelines can range from minutes for demand access users, to a year or 
more. 

The concept of a flexible request language was discussed as a potential 
candidate for the user POCC interface. This flexible request approach 
represents a major change in operations concept. Today the user submits 
(and resubmits) specific requests and receives a yes/no response. In 
flexible request scheduling, the user thinks through all service options and 
codifies flexible service windows in a request language. The SNC 
scheduling system then has more information to work with in attempting 
to satisfy flexible requests, increasing the likelihood of success. 

Flexible requests identify service resources and the times they are required, 
how often a service is required, expiration dates of service need, and 
alternatives if a service isn't available. Flexible requests can be 
characterized as having: 

• two dimensions, flexibility and repeatability; 

• three types of flexibility: time, request priority, and resource 
alternatives; 

• specific requests as a special case, where flexibility is 0 and there are 
no repeats; 

• definable dependencies/constraints; 

• symbolic definitions which can be referenced by name; 

• expressions of simple or complex relationships (a language). 

Two key points implied by the flexible requests approach should be noted. 
First, SNC and the POCCs should have standard access to scheduling data 
services (e.g., ephemerides, acquisition times) and mission elements (e.g., 
antenna models, spacecraft day/night calculations). This data is required 
for expanding and interpreting flexible requests. General scheduling 
constraints used by many missions should be maintained by MO&DSD and 
provided as a user service, whereas mission unique constraints should be 
supplied by the POCC. 

Second, incentives for efficient utilization of SN resources and the 
scheduling process should be provided. A problem in today's scheduling 
process is the tendency for users to overschedule resources, in anticipation 
that some requests will be rejected. If user POCCs can be encouraged to 
specify flexibility in their requests, then the scheduling system can better 
accommodate their requests, eliminating the need for extensive 
rescheduling. Incentives are recommended for early submittal of 
requests, for including flexibility in specifying requests, and for 
maintaining that flexibility late into the timeline. 
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A proof of concept for generating schedules, using a prototype fle £ible 
request language called the Flexible Envelope Request Notation, has been 
successfully demonstrated and is discussed in Session 2 of the proceedings. 


Prototypin g for the SNC 

Building rapid prototypes of critical components of the SNC environment 
was discussed throughout the conference. Recommended prototyping goals 
are to provide an iterative format involving users (both SNC and J'UbL 
operators) in evaluating concepts and generating requirements, to guide 
decisions regarding levels of automation, to inject innovation, to mitigate 
risks and capture lessons learned. Further, resulting systems could be 
provided to the SNC implementing contractor. 

Prototyping is seen as a productive approach to answering some of the 
concerns raised during the conference, particularly regarding the flexible 
request concept and schedule generation, various operational scenarios 
(e.g., Shuttle launch slips), and user interface issues. Specific objectives 
were mentioned in the following areas: 


• Flexible Scheduling Requests - determine the balance of flexibility vs 
complexity, the computing power/speed required to schedule and the 
accessibility of scheduling information required to interpret flexible 
requests. 


• Nominal Operations Scenario - demonstrate the scheduling process 
using flexible requests, comparing timeline horizon models, and 
evaluating request processing/response times and request submittal 

requirements. 


• Rescheduling Scenarios - demonstrate the ability to develop alternative 
schedules, or wait lists to handle events including of Shuttle launch slips, 
spacecraft emergencies, targets of opportunity and service demand access 

needs. 


• Fault Management - demonstrate techniques for SN service outage 
detection and rescheduling. 


• Human-Computer Interface - illustrate coding and naming techniques, 
as well as graphics. 


• Scheduling Algorithms - evaluate search algorithms and metrics, 
scheduling goals and heuristics, and performance issues, especially in 
regard to the impact of rescheduling. 


• Schedule Timeline - evaluate alternative timelines ^[schedule 
generation such as the forecast and active periods for NCC scheduling, 
addressing batch schedule processing with interactive rescheduling vs the 
continuous incremental scheduling model. 
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• Schedule Quality - define criteria for evaluation, determine statistics for 
measuring quality, and evaluate the effect of priority schemes, scheduling 
goals, and scheduling algorithms on schedule quality and efficiency. 

Conclusions 

The SNC Conference on Resource Allocation Concepts and Approaches 
generated a wealth of ideas for consideration during the SNC definition 
period. Many of the recommendations are being pursued or investigated 
further in the various SNC development tasks. A prototyping effort for SNC 
is underway to address as many of the suggested topics as time and 
funding will support. An initial testbed is planned to be established by the 
end of FY91 and will include an SNC scheduling prototype and a user 
POCC workstation interface. The testbed operations scenario will 
demonstrate the use of a flexible scheduling request language and operator 
tools for generating and maintaining an SN schedule. Those involved in 
the SNC development will continue to seek input and guidance from 
individuals and institutions involved in SN scheduling. 
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Section 1 — Introduction 

The goals for the Space Network Control (SNC) conference were to survey 
state-of-the-art efforts in planning and scheduling, assess their 
applicability to the Space Network (SN) domain of the late 1990s, and make 
the information and ideas raised during presentations and discussions 
available in proceedings to those responsible for the SNC definition. 


1.1 Background 

By way of background, the Network Control Center (NCC) of today is 
providing scheduling and technical management functions for the SN, 
ground network and interfaces to other networks such as the Deep Space 
Network. But the SN is changing with the Advanced Tracking and Data 
Relay Satellite (ATDRS) services, a possible mixed fleet of TDRS and 
ATDRS, the updating of the TDRSS ground terminal and other ground 
functions (e.g. NASCOM), and interoperability with the international space 
network community. It is becoming increasingly difficult to maintain the 
current NCC to meet these new challenges. 

Therefore, the goals for the SNC are to create a system architecture capable 
of accommodating changes in hardware, software, interfaces, and span of 
control. Also, the SNC program desires to improve the SN user's 
satisfaction by improving the user interface, accommodating varying levels 
of user sophistication and need, and increasing the percentage of support 
requests granted. This is to be accomplished while improving the 
utilization and effectiveness of SN institutional facilities, including 
operations and maintenance costs (SNC life cycle costs), as well as system 
reliability and resource scheduling. A 5 % increase in scheduling efficiency 
may save the cost of an ATDRS over the 15 year program life cycle (a 
savings of approximately $200-300 M). 


1.2 SNC Challenges 

The scheduling challenges facing SNC include making efficient use of 
network resources, minimizing the impact of Shuttle scheduling on other 
users, improving the user POCC interface for SN scheduling, refining the 
procedures for the scheduling process (e.g. the forecast and active periods), 
scheduling to avoid RF interferences, and providing better tools for conflict 
resolution. Some demands of the systems of the late 1990s include 
managing the transition from today's TDRSS to the ATDRSS and from the 
NCC to the SNC, scheduling support for the Space Station Freedom, 
proximity operations (e.g. Shuttle and SSF), international space network 
interoperability, and the concept of demand access to SN services. The 
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partitioning of functions between human operators and automated systems 
will be a key SNC issue, as will be the concept of making flexible scheduling 
requests, sometimes referred to as "generic scheduling". 

Recommendations from a recent GSFC study on planning and scheduling 
lessons learned in the Mission Operations and Data Systems Directorate 
(MO&DSD) were presented at the conference. Personnel from eight 
missions and several MO&DSD institutional facilities were interviewed to 
identify relevant mission characteristics and analyze lessons learned. Key 
recommendations presented were to develop end-to-end planning and 
scheduling operations concepts by mission class; to create an 
organizational infrastructure at the directorate level, supported by a 
steering committee with project representation, responsible for systems 
engineering of end-to-end planning and scheduling systems; and to use 
modeling capabilities and other system engineering tools to ensure that 
mission design impacts on planning and scheduling systems are 
understood early in the system life cycle. The study emphasized the need 
for flexibility in the operation of the Advanced Space Network, other 
institutional resources, and external (e.g. project) capabilities including 
operational software and support tools. 


1.3 Conference Format 

The SNC conference was designed to provide a forum for discussing these 
topics and capturing the highlights for use by SNC designers. Three 
sessions were defined to focus attention on first the concept and system 
engineering issues, second on the more visible human-computer interface 
and end user interface issues, and finally on the technology and tools that 
are evolving to address resource allocation problems. By surveying space- 
related literature and by pursuing personal contacts, a series of 
presentations were selected for the sessions. Each session was followed by 
a working group discussion. Discussion leaders assisted the smaller (7-9 
participant) groups in addressing the session topics, and elicited 
observations, issues, and questions from the participants. Each group was 
further assisted by a reporter to help capture the highlights of the 
discussions for these proceedings. In all sessions, lively discussions 
ensued and thorough rough notes were generated. Complete copies of the 
agenda, discussion topics, presentation handouts, and a list of attendees 
are included in the appendices. 
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1.4 Acronyms 


AI 

ATDRS 

ATDRSS 

Artificial Intelligence 
Advanced TDRS 
ATDRS System 

BER 

BFSSE 

Bit Error Rate 

Best First Search for Schedule Enhancement 

CHIMES 

CDOS 

COMS 

COMPASS 

CPU 

Computer-Human Interaction ModElS 
Customer Data and Operations System 
CDOS Operations Management System 
COMPuter Aided Scheduling System 
Central Processing Unit 

FERN 

Flexible Envelope Request Notation 

GCM 

GCMR 

GSFC 

Ground Control Message 
GCM Request 

Goddard Space Flight Center 

HCI 

HST 

Human-Computer Interface 
Hubble Space Telescope 

JPL 

Jet Propulsion Laboratory 

LDBP 

Long Duration Balloon Project 

MO&DSD 

Mission Operations and Data Systems Directorate (Code 500) 

NASCOM 

NCC 

NASA Communications System 
Network Control Center 

OMP 

ODM 

Operations Mission Planner 
Operations Data Message 

POCC 

PSAT 

Project Operations Control Center 
Predicted Spacecraft Acquisition Times 

RALPH 

RF 

ROSE 

RSA 

Resource Allocation Planning Helper 
Radio Frequency 

Request Oriented Scheduling Engines 
Range Scheduling Aid 

SAR 

SIRD 

Schedule Acquisition Request 

Support Instrumentation Requirements Document 
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SCAN Scheduling Concepts, Architectures and Networks 

SME Solar Mesospheric Experiment 

SN Space Network 

SNC Space Network Control 

SOLSTICE Solar Stellar Irradiance Comparison Experiment 
SURPASS Science User Resource Planning And Scheduling System 
SSF Space Station Freedom 

STGT Second TDRSS Ground Terminal 

TAE+ Transportable Applications Executive Plus 

TDRS Tracking and Data Relay Satellite 

TDRSS TDRS System 

TOPEX Topography Experiment 

TRUST TDRSS Resource User SUpport Tool 

UAV User Antenna View 

UPS User Planning System 


WSC White Sands Complex 

WSGT White Sands Ground Terminal 
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Section 2 — Conference Overview 


The following sections provide a brief overview of the material presented in 
the three conference sessions. Readers are encouraged to refer to the 
complete conference handouts provided in the Appendix. Several 
presentations included written papers, also provided in the Appendix. 
Other reference papers are organized in the bibliography by session. 
Following presentation highlights for each session is a synopsis of the 
working group discussions, derived from notes from the seven working 
groups. 


2. 1 Concepts for Space Network Resource Allocation 

The first session was intended to provide a framework for discussing end- 
to-end concepts for SN scheduling, with many topics being investigated 
further in later sessions. Papers were selected to reflect systems 
engineering perspectives, or to suggest considerations for the SNC 
operations concept. 


2.1.1 Session 1 Presentation Highlights 

Concepts. Requirements and Design Approaches for Building Successful 
Planning and Scheduling Systems , Rhoda Hornstein, NASA HQ Code OX, 
and John Willoughby, Information Sciences Inc. 

The first briefing provided a programmatic perspective on building 
planning and scheduling (P&S) systems, which were described as 
primarily human decision support systems that determine how shared 
resources will be managed. Their objectives are to make accurate and 
timely assignments of resources; identify, avoid, and resolve conflicts; 
provide effective and complementary human-to-computer interfaces and 
uncomplicated human-to-human interfaces. 

The challenge to managers of P&S efforts is to achieve operational 
effectiveness, by doing the right job efficiently and extensibility, by planning 
to accommodate change. Doing the right job entails focusing on system 
engineering to define and build the 'right system' rather than to define and 
follow the 'right process'. This implies developing competing alternative 
operations concepts, prototyping, and defining operations effectiveness 
criteria for acceptance testing. The second challenge, accommodating 
change, is aided by specifying requirements at a 'class' level by recognizing 
general case relationships that drive design (e.g., object-oriented design 
approaches). Other aids are the use of data or rule driven tools, and the 
development of an evolutionary acquisition strategy wherein layers (rather 
than segments) of the system are iteratively designed and implemented. 
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Prototyping is used to provide operations feedback on requirements to 
support design. 

P&S systems are challenging because the product, i.e. the schedule, is 
difficult to quantify (as it represents acceptable compromises), it is dynamic 
(what was acceptable many times in the past may no longer be), and it 
depends on the process used to generate it. The schedule s merit is process, 
not product dependent. That is, even an inferior solution may be deemed 
acceptable, if it is known that a number of alternatives were examined, and 
this solution is seen as the best that can be done. Also, the information 
flow between requester and provider must be balanced between the 
frequency of messages and their length and complexity. 

Some design recommendations are as follows: 

• Design the system as a replanning system since planning is a special 
case of replanning, and demand access can be accommodated as a special 
case of planning. 

• Design a decision support system and initially allow humans to make all 
decisions; then delegate routine decisions to machine processing using 
algorithms which emulate human decision behavior. (Let operations 
determine what is routine.) 

• Pool resources to accommodate requests for any quantity of a shared 
resource and handle individual resources as a special case of pooled 
resources. 

• Handle general temporal relationships, then accommodate sequence 
relationships as special cases (predecessor/successor, 
minimum/maximum delays, etc.). 

CQMS Planning and Scheduling Concept Assessment.. Todd Welden, 
Computer Sciences Corp. 

Study results performed for the Customer Data and Operations System 
(CDOS) Operations Management System (COMS) were highlighted. Major 
concepts promoted are flexible scheduling (also called generic scheduling) 
via a flexible request language, and open access to (non-secure) scheduling 
information via databases and networks. 

The flexible schedule requests approach allows users to symbolically define 
and reference constraints, request repeatable resource sets, and express 
complex relationships, flexible time durations, and flexible resource 
requirements. A major benefit of this approach is efficiency, since more 
information (flexibility) is supplied to the scheduler, increasing the 
probability that a request can be satisfied. At the same time this approach 
supports very specific requests without any flexibility. 
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A standard, robust, readable, and flexible scheduling request language is 
recommended for the SNC/user POCC interface. Such a language would 
allow the standardization of scheduling engines to process requests, and 
would also be applicable to mission scheduling beyond the SN. In addition 
to allowing users to specify flexible options for support, it allows the 
production of schedules which retain the flexibility information, resulting 
in potentially smaller impacts during rescheduling. 

Language features include the capability to add, delete and replace flexible 
and specific requests, individual request instances (generated from a 
repeatable generic request), pending requests, and scheduled events. The 
language can express user defined flexible time intervals (tolerances, 
windows) and sets (e.g. .spacecraft day), flexible request durations, generic 
requests which generate multiple events, and preferred and alternate sets 
of resources. The latter option allows the scheduler to determine which of 
the pooled resources to assign. 

It was recommended that the SNC maintain a database which contains 
configuration codes, ephemeris, user antenna view data, previously 
submitted user requests, and time interval sets. The motivation for this 
recommendation is that SNC is on-line and the missions require the same 
data needed by SNC. A central repository aids in data consistency and 
reduced data traffic and redundancy. Standard scheduling information 
products could be provided in response to user process queries in a 
standardized format. 

An RF Interference Mitigation Methodology with Potential Applications in 
Scheduling . Y. Wong, GSFC 531, and James Rash, GSFC 531 

This presentation recommended that scheduling time constraints 
calculated using RFI mitigation techniques be an input to the scheduler. 

A methodology and a prototype tool were described for determining the 
separation angles between antennas for any two user spacecrafts to avoid 
signal interference and to assure BER link margins (reference complete 
paper in Appendix C). The methodology determines potential interference 
time intervals for a given spacecraft and suggests that these data be 
provided to the scheduler as additional constraints. This approach is 
representative of a class of constraints derived from physical and orbital 
factors. Other members of this class may also be considered for use in SN 
scheduling. 

Automatic Conflict Resolution Issues , Jeff Wike, TRW 

Background information and several considerations for conflict resolution 
were presented (reference complete paper in Appendix C). The current SN 
conflict resolution process in the NCC is a verbal interchange between 
forecast analysts and user POCCs, since security considerations prohibit 
POCCs from accessing the entire schedule. The NCC scheduler software 
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emphasizes conflict avoidance. A recent analysis indicated that 90% of the 
conflicts were manually resolved (by alternate link assignments and/or 
time slips), which indicates that user flexibility exists. 

Automatic conflict resolution requires goals to guide schedule generation, 
and scheduling knowledge. Knowledge is both embedded in the scheduling 
system (e.g., user capabilities, preferences, SN resource data) and 
identified by the user POCC in each service request (e.g., tolerances, 
alternatives, mission unique constraints). However, it was noted that 
special circumstances will always exist which require manual conflict 
resolution (e.g., spacecraft emergencies). 

Some organizational goals which affect conflict resolution are priorities, 
assigned equipment links to specific users, not utilizing spare resources, 
maximizing use of single resources, leveling of resource utilization across 
the system, and rewarding cooperation. Potential conflict resolution 
strategies include priority schemes (varying priorities), shifting a service in 
time, shrinking service duration, using alternate resources, gapping (i.e., 
breaking and reestablishing) services, and finally deleting services. 

Effects of Locus of Resource Control on Operational Efficiency in Distributed 
Operations . Amy Geoffroy, Martin Marietta 

This presentation examined distributed operations from the science user 
perspective through hierarchical levels from control centers to SNC and SN 
facilities, to the spacecraft and finally to the science instrument. Key user 
scheduling issues are resource coupling (how tightly coupled is the 
communications service to instrument operations), demands of the mission 
for specific requests rather than flexible requests, and real time demands. 

The question of central vs distributed control was addressed. For decision 
making, control may be centralized in a distributed network, which eases 
the scheduling problem. If inter-node interactions allow services to be 
partitioned into smaller local networks, distributed control is preferred. 
Distributed control may be required because of security/privacy and 
authority issues. However, distributed control may compromise flexibility 
or efficiency. Also, flexible requests, though more efficient to schedule, do 
pose difficulties in the distributed control of tightly coupled resources. 

For centralized control with distributed access, globally available 
information and globally established priorities are necessary for decision 
making. Other scheduling approaches recommended for investigation are 
block resource allocation, cross-scheduler negotiations, and control re- 
directions. 

Resource Allocation Planning Helper - RALPH . David Werntz, JPL 

The final paper in the first session discussed the approach and lessons 
learned from the RALPH system. RALPH was developed to plan the Deep 
Space Network and became operational in 1987. It generates schedules two 
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years in advance. During the eight week period prior to an encounter and 
during real time, rescheduling is handled manually. 

A key lesson learned, as noted in their paper in the 1990 Goddard 
Conference on Space Applications of AI (see Bibliography), is that the 
system initially conceived and requested by users may not be the solution of 
their problem. The scheduling methodology may change in response to the 
power of the tool provided. 


2.1.2 Session 1 Working Group Notes 

The following topics were provided to the Session 1 working groups to 
promote discussion. 

Session 1. Concepts for Space Network Resource Allocation 

1. Identify the 3 most critical issues for Space Network resource 
allocation in terms of: 

a) Management 

b) Operations 

c) SN User POCCs 

d) System Development 

Include a sentence or two, as needed, to explain/clarify each issue. 

2. Select at least 3 of the critical issues above and suggest ways of 
resolving them. Address innovation and risk factors. Identify areas 
for further study and suggest study approaches. 

3. Discuss how resource allocation might be performed for: 

a) Rescheduling in the event of a failure to the ATDRSS Ground 
Terminal. 

b) Scheduling of previously allocated resources that unexpectedly 
become available (e.g., Shuttle launch slips). 

4. Discuss the pros and cons of dividing the schedule timeline into 
forecast (batch) and active (incremental updates) periods. Suggest 
alternative schedule timeline approaches for SNC consideration. 

5. Given that there are different user classes, discuss the pros and 
cons of subdividing available resources into multiple subnetworks 
based on user classes and demands for use by each user class. 

The first discussion topic was intended to identify critical issues for Space 
Network (SN) resource allocation in terms of management, operations, SN 
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users, and system development. Suggestions for resolving issues, 
innovative ideas, and risk factors were solicited, and recommendations are 
grouped below. A final section groups the questions generated. 

2. 1.2.1 Management 

Improve Us er Understanding of SN Services 

A major issue brought out in most groups addressed the need by the SN 
users to understand SN and SNC capabilities and limitations so that their 
service expectations are realistic. Users also need to consider the impact of 
spacecraft design and operations on SN resource availability and 
utilization. However, they should not need to know the operational details 
of the SN to use its services, as they do today. Likewise, SNC should 
demonstrate an understanding of user needs, and that these needs differ by 
spacecraft class, rather than consider all users to be the same. 

Furthermore individual users in the POCC, including developers, 
scientists, and schedulers, have different perspectives and needs. 

Many groups endorsed the recommendations made by Toni Robinson in the 
introductory presentation that the Mission Operations and Data Systems 
Directorate (MO&DSD) establish a management forum for end-to-end 
planning and scheduling issues. A key directorate level product would be 
operational guidelines for intersystem engineering, including an outline of 
SN objectives and end-to-end operations concepts (such as nominal 
operations, SN failure contingency, and rescheduling after a Shuttle 
launch slip). These guidelines would bound MO&DSD obligations levied by 
the mission Support Instrumentation Requirements Document (SIRD). 

Suggested topics for the guidelines, some of which exist in current 
documents, are technical overviews of the SN (spacecraft, ground 
terminals and SNC), resource availability profiles and service capabilities, 
and the flexible request capabilities. User considerations, such as the 
advantage of being able to use more than two ATDRSs if onboard ATDRS 
ephemerides are available, could also be discussed. 

Finally, MO&DSD should provide a help desk to assist users in developing 
end-to-end planning and scheduling operations concepts as well as to help 
in day-to-day problem solving. 

SNC Scone 

A related suggestion is to explicitly and clearly delineate the SNC control 
scope, defining end-to-end responsibility and authority. This delineation 
includes establishing a clear locus of control and functional allocation 
between POCC users and the SNC. The SNC should not make major 
modifications to accommodate an individual user’s unique needs. 
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There are also issues to be addressed in SNC’s role to existing missions 
served by today s NCC. Should the SNC be backward compatible to the 
NCC? Or is it reasonable to require current missions to upgrade their SN 
interface in 5-7 years? 

SNC Operations Concent and Requirements 

High level management approval of a comprehensive scheduling 
operations concept, encompassing user POCC, SNC, NASCOM II, CDOS 
and WSGT/STGT, is a necessary prerequisite to developing an end-to-end 
scheduling system. Management must mediate the tendency for 
organizations to want exclusive control over their own resources. 

Generation of this operations concept must involve operations personnel 
throughout the SNC system life cycle. A management commitment is 
needed to make operations personnel sufficiently available to support such 
non-operations functions. The issue is that there is too much software 
influence, and too little systems engineering and operational experience 
involved in current system development decision making. Extensive use of 
NASA in-house scheduling experience is also recommended. 

It is recommended that requirements be developed from the user POCC 
view, not the SN/SNC developer view. A key issue raised is how to get end 
users involved in the SNC definition process, primarily the operations 
concept and requirements. The trend for missions to use distributed 
systems with remote user capabilities may also have implications on SNC. 

Recommendations and investigations affecting the SN operations and 
policy which require management endorsement include: 

• Develop a new standard interface between the SNC and user POCC based 
on the flexible request scheduling concept. 

• Investigate allowing mission priorities to vary over time or by request 
within pre-specified bounds. 

• Investigate using spare SN spacecraft for peak loading periods. 

User POCC Requirements for SN Services 

The users POCCs should be giving the SN their service requirements, 
rather than specifying solutions. A complimentary recommendation is 
that SN personnel be involved in defining and developing spacecraft 
communication requirements. For example, one mission had planned on 
relying entirely on real-time operations for data transfer. The NCC 
explained the operational complexity and risk involved with this plan. The 
mission then modified their operations concept to include tape recorders. 
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2. 1.2.2 Operations 


SN Schedule Quality 

Discussions in this area raised many questions. For example, how should 
schedule quality be determined? What is the criteria for a good schedule? 
Goals, heuristics, optimization, and user satisfaction (defined here as 
meeting stated mission objectives and applying principles of priority) are 
factors to consider. 

Schedule Automation 

Based on NCC experience, automation of some scheduling functions is 
crucial to more efficient operations. However the level of detail within 
constraints that can be captured by automated techniques is a concern. 

One stated view is that "medium bright" human beings are necessary to 
successful scheduling systems since some constraints are not conducive to 
automation (e.g., political decisions). Providing automated tools to assist 
operations personnel with their jobs is suggested. 

Another viewpoint is that the SN scheduling problem is well known and 
can be modeled by analyzing the NCC. Therefore a fully automated 
scheduling system, which allows operators full visibility into the entire 
process and manual overrides by exception, is possible. 

The Scheduling Process 

There were a number of recommendations regarding the scheduling 
process. Rescheduling and contingency planning are big issues in today s 
NCC. It is recommended that planning follow the same process as 
replanning, not two separate processes. Another suggestion is to integrate 
all SN facilities (i.e., spacecraft, ground systems and networks) into one SN 
schedule. Others suggested pre-allocating blocks of services to high priority 
users, who then return unused resources when their plans are firm. 

Interoperability with other networks, including international networks, is 
a new concern which needs to be considered in the scheduling process. 

SNC Accountability 

Efficient use, as viewed from both resource utilization and user 
effectiveness, is a key issue. A trend was noted for low priority users to be 
more efficient than high priority users. High priority users tend to ensure 
availability and cover unknown contingencies by overscheduling. One view 
is that users know a certain percentage of requests will be rejected, so they 
overschedule. Today Landsat is the only mission charged for SN services, 
and the only one to delete requests for services no longer planned for use. 
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SNC should integrate service assurance and accountability with the 
scheduling process. Accounting statistics should address the number of 
requests submitted, modified, resubmitted, percent accepted, and compare 
the results to the SIRD commitments. 


2. 1.2.3 SN User POCCs 

User Accommodation vs Standards 

There is a delicate balance between accommodating diverse user needs and 
providing manageable standard services. It is important to define the 
standard POCC and SNC interface to accommodate a range of users. A key 
concern is how the SNC can be more responsive to the variety of users. One 
approach is to define user categories and a spectrum of standard options 
available in each category. The SNC must consider how best to 
accommodate both secure and non-sccure users with minimal impact on 
operational efficiency. The apparent dichotomy between flexible users and 
those with a need for demand access also needs to be addressed. 

The potential exists for the development of common tools shared by SNC 
and users. Regardless of the source, tools for the user POCC and the SNC 
need to be compatible, and use the same language. 

It is suggested that a conference of a similar format to this one be organized 
for user POCCs to discuss their requirements for the SNC. 

Flexibility and Incentives 

The concept of flexible schedule requests is recommended. This concept 
requires users to define their points of flexibility, and is discussed in detail 
in session 2. The specific scheduling of today is equivalent to the minimal 
form of flexible scheduling with tolerance parameters set to zero. A 
concern was raised regarding the potential for flexible requests to unduly 
increase the complexity of the scheduling system. 

Another concern is the tendency for users, especially new users, to over 
subscribe resources. Incentives are needed which act to promote efficiency, 
and to reward cooperation and the use of flexible requests. 

Some discussion revolved around how the SNC can be more responsive to 
low priority users. A free enterprise concept is suggested, where users are 
allocated points according to their priority, and points are exchanged for 
resource requests. For example, more specific (less flexible) resource 
requests cost more points than flexible requests, but utilizing suddenly 
available resources (e.g., from a Shuttle launch slip) would require very few 
points. A dynamic priority scheme may be employed to allow low priority 
users to eventually be scheduled. 
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Data rates today are fixed to a known set of values, but other standard SN 
service modes could be defined. The "TDRS wildcard" is an example where 
users simply request the service mode and the scheduler determines which 
spacecraft resources to allocate. Will users be willing to accept multiple 
access services instead of single access? Flexible requests could specify rate 
and data quality parameters rather than single or multiple access mode. 
The flexible request approach also implies that standard constraints, such 
as definitions for time periods (e.g., Monday afternoon" is anytime from 
12:00 to 4:59) or common orbital events (South Atlantic anomaly) are 
maintained as a service to all users. However, mission unique constraints 
would be submitted as time intervals in the user's requests. 

Information Access and Timing 

Authorized users will require easy access to common planning and 
scheduling information. Information needs and timing of feedback on 
schedule results (i.e., when users require resource commitments so that 
other payload operations can be prepared) may vary for different user 
classes. 

User POCCs have different timing drivers based on the science mission and 
the spacecraft characteristics. The feasibility of varying the SNC 
scheduling timeline by user or user class should be investigated. Today's 
NCC forecast/active timeline is restrictive to many users. Reactive 
scheduling and real-time operations are particularly difficult. 


2. 1.2.4 System Development 

Design Drivers 

A major SNC challenge is to design to accommodate change. Modularity 
emphasizes small, loosely coupled functional implementations rather than 
traditional system builds of a monolithic system. Modularity also allows for 
greater adaptability and the potential to "undo” individual automated 
functions should the operations concept be deficient. Design should be 
driven by functional performance requirements rather than a detailed 
specification. Requirements should be determined and confirmed by 
prototyping and by operations and user feedback throughout the system life 
cycle. Also, consideration should be given to the testability of the 
scheduling system requirements. 

Recommendations include use of system engineering methodologies which 
advocate re-use, extensibility, and standardization and which employ 
software development and delivery environments. One group comments 
"push systems engineering instead of engineering systems". Finally, the 
development of the SNC and user POCC interface should be tightly coupled, 
and the operational compatibility between the systems tested. 
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Technical Issues 


A single architecture for scheduling and rescheduling is recommended 
rather than a separate system for each. The architecture and information 
traffic flow for distributed control should be determined. A networked 
architecture for the SNC is one alternative that has been offered for 
consideration. 

Prototyping is suggested as a means to validate alternative designs and 
study automation issues. Automatic checking of requested services for 
compliance with technical scheduling constraints such as RFI mitigation 
should be considered. 

Methodologies 

Rapid prototyping utilizing iterative build (design and implement) and 
evaluation cycles, is highly recommended as a means for users to define 
requirements and validate operations concepts. The term "spiral 
prototyping" with user involvement at each cycle is used to convey the 
desired iterative approach. 

Other methods suggested include: 

• Modelling operations at a significant level of detail. 

• Using a design team approach with members from all elements which 
could be affected. 

• Using an object-oriented design to maximize flexibility (C++ language for 
prototyping, class libraries, Ada for supporting system evolution). 

2. 1.2.5 Session 1 Specific Questions 

Responses to three additional questions posed to the working groups are 
summarized below. 

Resource Allocation Concepts for Contingency Rescheduling 

Several groups commented that the flexible request scheduling approach 
aids rescheduling, provided flexibility information is maintained and 
remains valid. 

Rescheduling in the event of a failure to the ATDRSS Ground Terminal. 

Minimum requirements for anticipated contingencies should be defined 
during mission planning. One suggested approach for dealing with a 
ground terminal failure is as follows: 

• At time of failure, determine user impacts and criticality. 

• Perform reschedule based on current priorities. 
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• Exploit the potential for automating "minimally disruptive" scheduling 
techniques. 

• If needed, replan entirely after a specific lead time (e.g., replan all events 
24 hours after failure). 

Scheduler tools, like editors, should be designed to allow easy access to 
information so that rescheduling may be performed quickly. Disturbance to 
the overall schedule should be minimized. 

Scheduling of previously allocated resources that unexpectedly b ecome 
available (e.g.. Shuttle launch slips). 

The ability to take advantage of opportunities to schedule additional 
resources in this case must be designed into the system from the start. 
Using a Wait List is recommended. Users can be prepared to execute 
activities, which were pre-planned for the event of a launch slip. In other 
words, alternate schedules are developed in parallel to utilize pre-allocated 
resources. This concept is feasible because state of the art scheduling 
techniques are very time efficient. Break points in the timeline are needed 
to effectively return to the primary schedule after the contingency 
operations are completed. 

Schedule Timeline Alternatives 

The pros and cons of dividing the schedule timeline into forecast (batch) 
and active (incremental updates) periods were discussed. Alternative 
schedule time spans of months, days, and minutes were suggested. 

The current 14 day forecast period is considered too long and forces 
overscheduling. Instead a 4 day forecast period is proposed, and considered 
a possible change even for the current NCC. 

One group stated that some type of forecast and active periods are inherent 
in any scheduling problem. Batch processing of requests provides more 
efficient scheduling. Low priority users may favor forecast schedules since 
it "guarantees" support. However the current scheme discriminates 
against missions that don’t or can't plan in advance, and it is difficult to 
accommodate late changes. 

Another group suggested a more continuous timeline, spanning months 
instead of days. Users submit requests when it is best suited for them to do 
so. Therefore there exists a firm schedule in near term, but a softer, 
sparsely populated schedule in the future. This approach is useful in 
accommodating surges in service requests. However, at some point prior to 
execution, everyone must commit to the schedule. 

Missions with complex operations may require more lead time to generate 
payload commands based on a committed schedule. Others may be able to 
live with schedule uncertainty until very near to execution. Mission factors 
affect the user's view of the timeline. For example, Hubble Space 
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Telescope's natural planning cycle for observations is a year, whereas 
Landsat's window is 16 days (to completely cover the earth). 

Other comments include: 

• Use a flexible scheduling language and rewarding flexible requesters; 

• Penalize resource wasting; 

• Negotiate commitments through established guidelines; 

• Report to users the likelihood that they will be scheduled; and 

• Consider dynamic and multiple priority schemes. 

Subnetworks 

Participants were asked to discuss the pros and cons of subdividing 
available resources into multiple subnetworks based on user classes and 
demands for use by each user class. Dedicated resources (equipment 
chains) are scheduled today on an informal basis (e.g., one antenna is 
reserved for Shuttle) and this could be made into a formal operations 
concept. Advantages of this approach are that subnets may better 
accommodate users who can't plan in advance, by setting aside a pool of 
resources for their use. Subnets may also allow easier scaling up for 
increased services, (e.g., add a new subnet when a new satellite comes on- 
line). If secure operations were partitioned to one subnet, then non-secure 
missions could potentially operate in the open. 

Some questions are raised concerning how to avoid underutilization of 
some subnets. Transferring resources between subnets to achieve efficient 
load distribution and the impact of launch slip rescheduling on users both 
need study. 


2.2 SNC and User POCC Human-Computer Interface Concepts 

This session focussed on two types of user interface considerations. First 
human-computer interface issues were discussed from both the SNC and 
user POCC operators point of view. Next, the system level interface between 
the SNC and its users, the POCCs, was addressed in the context of a 
human readable scheduling interface language. 


2.2. 1 Session 2 Presentation Highlights 

User Interface Issues in Supporting Human-Computer Integrated 
Scheduling . Lynn Cooper, JPL 

The insights presented are based on experience with JPL's Operations 
Mission Planner (OMP), an automated scheduling prototype using an 
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iterative refinement approach based on AI technology. The OMP 
scheduling domain is over-subscribed with large numbers of complex 
requests. JPL's research centered on minimally disruptive replanning and 
the use of heuristics to limit the scheduler's search space. (See 
Bibliography for OMP references.) 

The OMP user interface was designed as a developmental, rather than an 
operational interface. It was used to develop and debug heuristics, to 
enable developers to assess OMP's progress toward completing a schedule, 
and to allow others to visualize the OMP multi-phase approach to 
scheduling (i.e., what actions are being performed and why). By contrast, 
an operational interface would address how operators use OMP in an 
operational environment. Operational utilization would require additional 
heuristics to interact with users, provide feedback on how user actions 
affect the schedule, and assist users in performing interactive scheduling 
(providing guidance to the schedule operator). 

There are two major considerations in specifying a user interface. The first 
is the functional distribution between automated functions, which are 
process oriented (develop, assess, modify schedule), and human functions 
(identify new heuristics, direct/guide schedule changes, monitor and verify 
schedule execution, identify problems). The second consideration is the 
type of user, such as the schedule system operator (who adjusts the process, 
interprets results of algorithms, modifies/develops new heuristics, 
analyzes performance statistics) and the schedule end user (who requests 
activities, sets preferences, defines limits/tolerances). 

In OMP the human operator controls the processing with the same degree 
of authority as the automated control heuristics. User modification to a 
schedule is considered, but is not necessarily absolute. A dynamic overlay 
technique allows the user to identify the preferred location of an activity on 
the schedule timeline, but the scheduler algorithm may move it to resolve a 
conflict. If the user moves it back to the previous location, the scheduler 
overlay increases the weight of preference and does not move it again. 

Human Factors Issues in the Design of User Interfaces for Planning and 
Scheduling . Elizabeth Murphy, Computer Technology Assoc. 

A NASA survey of planning and scheduling tools and analysis of human 
factor issues was presented. The study produced design guidelines with 
illustrative display concepts based on human factors literature. Some of the 
key issues found in the survey include: 

• The visual representation of the schedule to reflect temporal ordering of 
events 

• Evaluation of schedules to compare and select from alternatives, (e.g., 
histograms showing percent of criteria satisfied) 

• Identification of available resources to compare requested vs available 
resources 
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• Conflict resolution support, (e.g., highlight conflicts or suppress non- 
conflicting events). This support is based on analysis of the operator's 
goals and mental tasks. 

Some general recommendations for user interface design are to perform an 
operations task analysis and focus on the cognitive tasks, to support 
visualization and direct manipulation of data, and to involve operators in 
the development process. Detailed recommendations are found in the 
report referenced in the Bibliography. 

A Planning Language for Activity Scheduling . Stuart Weinstein, Loral 
AeroSys 

The Flexible Envelope Request Notation (FERN) discussed in this 
presentation was developed for NASA scheduling applications. Users 
generate flexible requests in FERN, which are then submitted to the 
Request Oriented Scheduling Engine (ROSE) for interpretation. ROSE then 
generates a schedule timeline of user activities based on FERN requests. 
The motivating factors for developing a scheduling language were 
readability, ease of use (e.g., default values need not be entered), and the 
ability to express options and alternatives all in one request. 

The language should be robust, keyword based (not positional) and object 
oriented (data abstractions with reusable data objects). It must support a 
variety of user resource requirements and constraints including alternative 
resource amounts, repetitive requests based on orbital events (vs specific 
start times), flexible time durations and relaxable constraints. FERN 
allows information flexibility in resource specification, request duration 
and repeatability, experiment timing and coordination between activities, 
alternative activities, and relative importance of each requirement. 

FERN requests are hierarchically structured, supported at the top level by 
generic (or flexible) requests, then activities, and at the lowest level, steps. 
Generic requests specify the pattern of activity replication, alternative 
activities, and the rules of request implementation. Each activity describes 
the sequence of steps which make up that activity, the duration of each step, 
and activity constraints. Steps define the resources required and any 
constraints on the step. Other key FERN structures include resource 
representations (pooled, durable or consumable, variable over time), 
constraints, and timegraphs (specifying different time periods). 

CHIMES: A Tool for HCI Analysis . William Weiland, Computer 
Technology Assoc. 

The Computer-Human Interaction ModElS (CHIMES) methodology and 
toolset was developed for evaluating existing human-computer interfaces 
(HCI) and for predicting design impacts and selecting design alternatives 
for planned interfaces. It assumes a functional hierarchy of mission, 
function, subfunction, task, and subtask. The system analyzes the 
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demands placed on personnel resources, i.e., cognitive (analytic, verbal), 
sensory (visual, auditory), and motor attributes. 

The CHIMES process starts with a model of the operator's job, and rates 
HCI demands on the operator (visual, etc.). The tools then evaluate or 
predict overall operator workload and performance, identify trouble spots 
(e.g., high or low workload, performance), and recommend improvements. 
The CHIMES prototype currently evaluates a single alphanumeric display 
screen (visual and analytic demand). CHIMES includes a sophisticated 
user-system interface, knowledge bases, display analysis tool, modification 
advice, and an explanation facility. Future development include graphics 
and color analysis, and a refinement of the CHIMES model. 

TRUST-An Innovative User Interface for Scheduling . Tom Spam, 
University of Colorado 

TDRSS Resource User Support Tool (TRUST) was developed to support 
TDRSS scheduling for flight projects at the Univ. of Colorado/Boulder 
including SME, SOLSTICE, TOPEX, and LDBP. It has also be used in 
planning and scheduling study efforts with GSFC including SURPASS, a 
comprehensive planning and scheduling tool for science experiment 
operations, which includes SN service schedule requests. 

TRUST is implemented in Ada and embodies an expert system to aid 
scheduling generic TDRSS support and providing automatic rescheduling 
for conflict resolution. TRUST processes current operational and quality 
data messages with NCC, checks constraints, and performs trend analysis 
of the TDRS link. TRUST receives and processes spacecraft and TDRS 
visibility and orbital data. Request generation and processing is handled 
via a menu driven user interface. The graphical interface supplies a view 
of possible activities in science context. 

The point was made that from the end user or science viewpoint, an 
integrated scheduling process for both SN and spacecraft resources is 
desirable. Color viewgraphs were included to demonstrate how TRUST 
operates. 

NCC User Planning System (UPS) User Interface . Brian Dealy, Computer 
Sciences Corp. 

UPS is a state-of-the-art replacement for the NCC Mission Planning 
Terminal which runs on Unix platforms with TAE+, a NASA developed 
graphical user interface based on X-Windows. UPS functions are to input 
and validate orbital data input and validate interactive and batch requests, 
transmit schedule acquisition requests (SARs) to the NCC, receive 
confirmed schedules, and report results. 

UPS interactive features include a top level information window with 
pulldown menus, which provide access to all subsystem capabilities. The 
POCC positions which would use the UPS are the mission coordinator (who 
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manages the data), the scheduler (who generates the requests), and the 
science user (who reviews the scheduling data). Tools assist the operator in 
mission setup (configurable for multiple mission support), database 
maintenance, and orbital data operations. UPS features automatic and 
specific schedule request generation (with default values where applicable), 
message transmission, and report generation. 

The operator can choose between graphic and tabular formats, where 
tabular data is arranged in an easy to interpret format. A display shows 
interrelationships between SN services, events, interference and inter- 
mission conflicts for resources. Scrollable displays are used for the TDRS 
and mission spacecrafts and time periods scheduled. Viewgraphs were 
included to demonstrate UPS display techniques. 


2.2.2 Session 2 Working Group Notes 


Discussion topics for Session 2 considered human factors issues for both the 
SNC and user POCC operators, and addressed the information interface 
between the SNC and the POCC. This interface has both human and 
electronic elements. 

The following four discussion topics were provided to the working groups. 

Session 2. SNC and User POCC Human-Computer Interface 
Concepts 

1. Using presentation materials as a baseline, provide a definition of 
"generic scheduling" and make recommendations for its use in 
terms of concept, requirements, and implementation approach. 
Discuss incentives to make generic scheduling an attractive option 
for user POCCs and provide rationale. 

2. Discuss the pros and cons of redefining the user POCC scheduling 
interface in conjunction with defining the SNC scheduling interface 
to the POCCs. Address the potential for providing common tools for 
user POCCs. 

3. Scheduling system user interfaces guidelines are not mature 
today and standards are not expected in the foreseeable future. 
Suggest steps that should be taken to incorporate human factors 
guidelines for the human-computer interface into the system 
development process. Address risk areas. 

4. Suggest an approach and discuss trade-offs for determining 
appropriate levels of automation for the SNC, for example, fully 
automated operations, human management by exception (supervisor 
role), human activated with computer assistance (computer 
recommends actions), or manual operations. 
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2.2.2. 1 Generic Scheduling 


The working groups were asked to define generic scheduling and to make 
recommendations regarding its use, including incentives. They were given 
the following suggested definition and graphic shown in Figure 2-1. 

Generic scheduling is a capability which allows scheduling of resources in 
response to user requests for single or repeated events in which time and 
resource requirements are expressed in a general way. Generic 
scheduling requests may include: 

• Time expressed in terms of acceptable windows of absolute time or in 
terms of relative time (e.g., relative to orbital or other scheduled events). 


• Resources expressed in terms of resource class and/or mandatory versus 
desired, (but optional) resources (e.g., willingness to accept one service 
without the other) 


Figure 2-1 Generic Scheduling Definition 


Request Flexibility 


- Requests for 
multiple 
activities with 
no flexibility 


m Request 
" Repeat- 
ability 

• Requests for a 
single activity 
with no flexibility 



The first recommendation is to use the more appropriate name, "flexible 
request" scheduling, since the term generic request already has a special 
meaning. For example, the ATDRSS Phase B Operations Concept (S500-3) 
has a definition of generic scheduling which addresses only the repetition 
of a request. Also the NCC currently performs manual generic scheduling 
for tracking data. The concept discussed here is a considerably broader 
concept. 
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Flexible requests identify the resources and times that are required, how 
often a service is required, expiration dates of service need, and alternatives 
for a service if it isn't available. Flexible requests can be characterized as 
having: 

• Two dimensions, flexibility and repeatability 

• Three types of flexibility - time, request priority, and resource 
alternatives 

• Specific requests as a special case, where flexibility is 0 with no repeats 

• Definable dependencies/constraints 

• Symbolic definitions which can be referenced by name 

• Expressions of simple or complex relationships (a language). 

A composite definition from all the groups follows. 

2.2.2.2 Definition for Flexible Requests 

Flexible scheduling is a capability which allocates resources in response to 
user requests for single or repeated events (indicating service frequency) in 
which time and resource requirements arc expressed in a general way. 
Flexible requests may include: 

1) time expressed in terms of acceptable windows of (predetermined) 
absolute time, of relative time (e.g., relative to orbital events or other 
scheduled events), and of variable duration; 

2) resources expressed in terms of resource class and/or mandatory vs 
desired (but optional) resources (e.g., willingness to accept one service 
without the other); 

3) alternate service requests (if request A cannot be satisfied, substitute 
request B); 

4) mechanisms for users to indicate request priority levels relative to their 
complete set of requests (i.e., within a system assigned range, users can 
select the priority level for a single request); and 

5) expiration dates for repeatable events and expiration times for when 
tolerance is no longer viable (i.e., when a mission must have a commitment 
for allocated resources. 

The ability for the scheduler to maneuver within the specified tolerance 
levels should be maintained as long as possible. 

New Operations Concept 

This flexible request approach represents a major change in operations 
concept. Today the user submits (and resubmits) specific requests with a 
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yes/no response until satisfied or rejected. In flexible request scheduling, 
the user thinks through all options and codifies flexible service windows in 
a request language. The SNC scheduling system then has more 
information to work with in attempting to satisfy flexible requests, 
increasing the likelihood of success. The MO&DSD needs to help users 
develop a new network utilization concept during mission design in order to 
take advantage of the new capabilities flexible scheduling offers. It is 
suggested that SNC provide a help desk for assisting POCC users with the 
transition to flexible request scheduling. 

As the scheduling problem is dependent on human judgement and 
cooperation, mutual trust between users and SNC is desirable. The SNC 
should believe that users won't overschedule because the likelihood of 
satisfying their requests is increased when the flexible options are 
specified. The users should believe that the SNC is giving them the best 
possible service because all the information to identify constraints and 
alternatives is provided in the request. Automated accounting of requests 
and of actual resource use by user is recommended to help establish trust 
and demonstrate that the SIRD commitments are being met. User POCCs 
may wish to approve the final instantiation of their flexible requests in the 
schedule. 

SNC needs to demonstrate improved success rates (i.e., less time to produce 
a better result) with flexible requests in a realistic system model. Prototypes 
for proof of concept and/or shadow systems, schedule products to compare 
with the specific scheduling approach, and case studies are recommended. 
Possible studies to perform include analysis of the NCC scheduling 
negotiation process, time spent scheduling HST over a limited time period, 
and statistics on rejection rates during a Shuttle launch window. 

Incentives are recommended to encourage users to submit flexible 
requests. Examples of incentives include a tax on disruptive requests, or 
conversely a discount for using a certain percentage of flexible requests, 
discounts for early submittal of service requests, or for maintaining 
flexibility late into the timeline. A multi-level "chip" method is suggested, 
where users are provided with a certain number of flexible request chips, 
and fewer specific request chips as an accounting mechanism. 

Concerns 

A number of concerns were raised. One involved the level of complexity 
introduced by a flexible request language approach. Concerns about the 
POCC passing too much information to the SNC also surfaced. The SNC is 
expected to handle orbital event times from missions as constraints. Some 
mission constraints can be very complicated, e.g., an instrument's view of 
spacecraft night and day may be dependent on the instrument's location on 
the spacecraft. Hence events could vary for different instruments on the 
same spacecraft. Specifying this type of constraint in a non-mission 
specific fashion is challenging. One approach is for the POCC to reduce 
these mission unique events into simpler time constraints. 
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Generic (repetitive) request scheduling is efficient for housekeeping, 
telemetry dumps, and other cyclical events, however it is not appropriate 
for one-time occurrences, which characterize many science events. Still, 
the flexible component of this approach is applicable to both kinds of events. 

A concern exists that users may neglect to cancel repeated service requests 
they no longer need, when they maintain a standing generic request for 
services. 

Training users and maintaining the language are also issues to study. 


2.2.2.3 Redefining the User POCC - SNC Interface 

This discussion topic explored the benefits and issues in developing a new 
scheduling interface for the user POCCs in conjunction with defining a 
new SNC. Future SN users should have all capabilities available today. 

The new SNC is seen as an opportunity to redefine the user POCC interface 
and implement new capabilities, especially flexible requests. Flexibility 
options should be encouraged, but not forced. One concern is whether 
existing users would have to upgrade their interface or if the new interface 
would be downward compatible. Security issues imposed on the flexible 
scheduling approach, if any, should be studied. 

Re-definition Approach 

It is strongly recommended that the new interface be defined and 
engineered by a single team with representatives from both the SNC and 
the user POCCs. Then each group could develop their respective part, but 
with continued interaction throughout the system life cycle. Standardizing 
scheduling terminology across the SN is suggested to aid this process. The 
interface should include a standard scheduling language for describing 
flexible requests and common tools to enable POCCs to efficiently use the 
interface. Understanding the needs of different mission classes could help 
provide appropriate common tools. Increased use of electronic networks is 
recommended for information transfer, reducing the need for phone traffic. 
Also, POCCs should have standard access to scheduling data services (e.g., 
ephemerides, time representations) and mission elements (e.g., antenna 
models, spacecraft day/night calculations). 

Tools 

POCC users should be provided with a modular package or toolset to 
integrate in whole or in part into their system. Users may require specific 
tools for mission unique requirements, and they may want to combine SN 
scheduling with instrument planning. Therefore, tools should be provided 
with optional hardware and modular software which runs on multiple 
hardware platforms. A reusable, object-oriented library of tools is 
suggested. Finally, tool use should be promoted, but not mandated. 
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2.2. 2.4 Human-Computer Interface Guidelines 

Working groups were requested to address risk areas and suggest steps 
that should be taken to incorporate human factors guidelines for the 
human-computer interface into the system development process. 

Industry standards addressing general user interface guidelines do exist 
and should be applied to the scheduling domain, and especially to the 
prototypes. Prototypes should be completed as early as possible and before 
critical design reviews begin. In this way human-computer interface 
(HCI) issues specifically relevant to scheduling can be compiled, creating a 
library of lessons learned that crosses mission boundaries. 

Operators and user class representatives who understand the scheduling 
process (not just the procedures in use today) should be involved in 
evaluating prototypes and throughout the SNC life cycle. User operators 
should be allowed to determine what is the best display, even allowing 
individual tailoring of displays within preset limits. 

User interface technology exists today, which enables operations to develop 
and evolve their own standard displays. The capacity to easily change 
displays exists in tools such as TAE+, which provide data independence 
from display software. The operations concept should guide the definition 
of display contents, and human factors guidelines should be applied to 
develop common shells for this data. Providing a similar look and feel to 
displays eases training and use. Object oriented design approaches are 
recommended to better accommodate evolutionary changes. 

Freezing user interface requirements too early and/or imposing a stringent 
scheduling language standard without adequate test and evaluation (via 
prototyping) are seen as key risk factors. Since scheduling operations 
represent a small and focussed group, the human factors engineering for 
SNC should emphasize expert users and tools for training, rather than 
attempting to accommodate novice users. 


2.2.2.5 SNC Levels of Automation 

Determining the appropriate level of automation for SNC is another risk 
area which the groups were asked to discuss. The NCC project suffered 
from an approach that implemented a fairly manual system (automated 
schedule generation with manual conflict resolution). The development of 
automated tools to assist operators was anticipated, however funds were not 
forthcoming. Changes in the evolving SN took on higher priority, so 
automation aids never materialized. 

Two viewpoints to consider are whether the SNC should basically be a 
manual system with automated pieces (e.g., tools), or an automated system 
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which allows manual operations by exception. It is not a question of 
manual vs automated, but rather a question of where on the continuum 
between manual and fully automated will the SNC be designed. If the 
design starts too far to the manual side, achieving higher levels of 
automation may not be feasible later, as in the case of the NCC. 
Alternatively, automation without the appropriate system hooks would 
require substantial changes to give operators the insight they need. 

One recommendation is to design the initial system to allow humans to 
make decisions (i.e., a decision support system). Operations personnel 
would identify routine decisions or procedures to delegate to machine 
processing (i.e., design algorithms to emulate human behavior). The 
converse recommendation stands on the premise that the SN scheduling 
problem is now well know and can be articulated and/or modeled by 
analysis of the existing system. Given this insight, a system could be 
designed with automated decision making capabilities, which provide 
operators with full visibility into the entire process, and allowing manual 
override by exception. 

The SNC operations concept definition process should explore these ideas. 
The discussion notes tended to emphasize a human centered system with 
operator tools, rather than a machine centered system with human 
tenders. It is recommended to always keep man-in-the-loop, because of the 
need for human intuition and for intervention in certain decision making 
and conflict resolution problems. For example, decisions based on policy 
are subject to change and therefore risky to model in software. 

Mechanisms are needed to add tools as experience dictates. 

Four methods recommended to determine automation requirements are 
task analysis, modeling, design team, and prototyping. Task analysis is 
used to identify and characterize tasks. The entire process, machine and 
manual procedures, must be analyzed with computer performance and 
operator skill being two criteria to consider. Automation should be based on 
which activities could be better performed by computer (e.g., repetitive 
tasks). The CHIMES tool and MITRE RSA project demonstrate this 
process. An end-to-end paper model of the NCC is recommended, using 
survey information of NCC operators and users regarding scheduling 
system objectives (not necessarily procedures). The design team approach 
involves representatives from development, operations, user classes and 
management in developing design alternatives. One caution is to avoid 
biasing SNC towards current operations just because people tend toward 
what they already know. Objective guidance is needed to identify tasks 
which could be automated. Prototyping allows evaluation of a mix of 
automated and manual operations. 
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2.3 Resource Allocation Tools, Technology, and Algorithms 


Several systems developed for specific projects were presented in this 
session to highlight the application of technology to similar scheduling 
problems. 


2.3. 1 Session 3 Presentation Highlights 

AI Scheduling Techniques for HST , Mark Johnston, Space Telescope 
Science Institute 

The Hubble Space Telescope (HST) offers one of the most challenging 
mission scheduling problems facing NASA. Scheduling HST involves 10 to 
30 thousand observations per year, with approximately ten interacting 
constraints (operations, resource, science) for each observation. Constraint 
timescales range from seconds to many months. Observation pools are 
intentionally oversubscribed (-20%), with the goal to maximize HST science 
(i.e., highest priority science and maximum data quality). The spacecraft 
and ground system were designed assuming predictive scheduling would 
be adequate, however uncertainty of orbit accuracy and guide star 
availability is a major problem. This presentation focuses on the Artificial 
Intelligence (AI) methodology used for SPIKE, one of the key tools created to 
aid in the planning process. 

The AI techniques implemented in SPIKE are used for constraint 
satisfaction techniques (search, constraint preprocessing) and weigh t-of- 
evidence combination for uncertainty reasoning. SPIKE supports 
automatic offline scheduling and graphical interaction by users to make 
scheduling decisions and diagnose problems. Its architecture features low- 
level constraint representation and propagation, and higher-level strategic 
scheduling (search). 

The SPIKE approach incorporated development of a suitability function 
framework where the suitability function is based on the scheduling 
expert's assessment of the degree of preference for scheduling an activity at 
some time within constraints. The framework can also represent trade-offs 
among preferences, uncertainty in predicted scheduling conditions, 
implications of scheduling decisions as they are made, and implications of 
task execution as the schedule is implemented. 
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Intelligent Perturbation Algorithms for Space Scheduling Optimization, 
Cliff Kurtzman, Space Industries, Inc. 

Optimizing a schedule generally results in a savings in time and money 
and by an increase in the fulfillment of mission goals. However, finding an 
exact, optimal solution to scheduling problems by searching is often not 
feasible, since the number of possible solutions is too large. Heuristic 
algorithms are then employed and can lead to a solution that is good , but 
not always "optimal". 

Intelligent perturbation heuristics are iterative refinement techniques and 
rely on "intelligent” search steps (rather than random) to systematically 
and quickly find good solutions. This technique has been implemented for 
Industrial Space Facility prototype experiment scheduler project. A more 
detailed paper is included in the Appendix C. 

The search operator should be able to span the search space in a small 
number of steps. The computational overhead of iterations should be small, 
compared to the cost of producing a schedule. Search algorithms should 
have a random component for avoiding loops and breaking away from local 
optima. 

A perturbation operator is used to increase rankings of activities not 
satisfied on previous iterations of the schedule, or rankings of bottleneck 
activities. Parameters can be adjusted to fit the structure of the particular 
scheduling problem, and the choice of parameters is key to finding good 
schedules (i.e., it is problem domain and policy dependent). 

Iterative search techniques and parallel processing are enabling 
technologies for schedule optimization. Mouse/window style interactive 
user interfaces and object-oriented programming have aided the software 
development process for scheduling systems. 

Combinatorial Optimization Techniques for Activity Scheduling , Surender 
Reddy, Computer Sciences Corp. 

Producing a good initial schedule based on subjective analysis is labor 
intensive, impractical and unnecessary. Initial schedules can be based on 
computationally efficient polynomial time algorithms to optimize a general 
objective (such as maximizing the number of requests satisfied). The final 
schedule then evolves through changes and fine tuning, based on subjective 
analysis and human interaction. 

A general approach combines optimization and heuristic techniques. 
Optimal single resource scheduling uses polynomial time optimization 
algorithms. Heuristic reasoning decomposes multiple resource problems 
into a series of single resource problems suitable for application of the 
single resource algorithms. 
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A proof of concept prototype was developed which can schedule specific and 
generic requests for TDRSS, DSN, and ground network services. It 
produced schedules with approximately 95% of the theoretically possible 
number of requests satisfied. The approach is applicable to initial batch 
scheduling and to certain cases of batch rescheduling. 

Range Scheduling Aid . James Logan, MITRE 

The Range Scheduling Aid (RSA) was developed to schedule the Air Force 
Satellite Control Network communication traffic. The initial approach 
involved scheduling on a paper wall chart completely by hand. MITRE's 
approach to developing a knowledge-based scheduling aid was to 1) 
replicate the current scheduling process in an automated environment; 2) 
develop a prototype based on user experience; and 3) create a user-friendly 
graphical interface. 

The RSA features a graphical user interface with a similar look and feel to 
the paper wallchart, but with real-time response to human interactions. A 
constraint based analytical capability provides scheduling tools and 
automates human scheduler heuristics. RSA has a real-time multi-user 
system implemented on a portable workstation in Common Lisp. 

The conflict resolution capabilities within RSA include identifying conflicts, 
oversubscribed resources and inadequate turnaround times. The tool 
provides explanations on conflict types and associated resources and times. 
Conflicts are resolved by listing possible solutions for single tasks and 
globally across time slices. 

The technology transfer approach started with a known (manual) 
scheduling process, and incorporated known user interface features 
(codified scheduled events with color and patterns that mimicked the look 
and feel of the wall chart). The human schedulers’ heuristics were then 
incorporated as computer aids in order to make their job easier and less 
prone to error. 

Scheduling Techniques in ROSE . David Zoch, Loral AeroSys 

The Request Oriented Scheduling Engine (ROSE) is a scheduling prototype 
that creates fast, automated conflict-free schedules. ROSE implements the 
Best First Search for Schedule Enhancement (BFSSE) post-processing 
algorithm among other rescheduling and contingency scheduling 
techniques. Graphical operator tools are provided for computer-assisted 
scheduling. ROSE goals are to: 

• Reduce the time to generate a conflict-free schedule, 

• Satisfy customers, 

• Respond quickly to changes (targets of opportunity, Shuttle slips), and 

• Implement NASA policy. 
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With ROSE users can submit flexible requests with preferences, constraints 
and alternatives by specified time. An initial conflict-free schedule is 
created by ROSE in 1-2 hours, with some requests not satisfied. Conflict 
resolution is performed by computer algorithms that imitate human 
conflict resolution processes (heuristics) in an attempt to schedule the 
remaining requests. The BFSSE conflict resolution approach identifies one 
unscheduled request and the algorithm repeats the following steps until 
either a solution is found or a timeout occurs: 1) select places on the 
schedule where the request almost fits; 2) move scheduled requests to place 
the unscheduled request; 3) reschedule all the moved requests by repeating 
the select/move steps for all moved requests. 

A TDRSS scheduling prototype used ROSE to evaluate generic (flexible) 
scheduling requests for the predicted 1995 TDRSS workload. Different 
request selection, placement strategies, and scheduling algorithms were 
used. Flexible requests represented realistic contention for TDRSS 
resources with realistic view periods for eleven missions. Tradeoffs 
between success rates and time-to- schedule for the different scheduling 
algorithms were analyzed. This prototype verified the ability of a flexible 
request language (FERN) to realistically represent missions' needs with 
about 1700 requests/week (without Shuttle requests). Flexibility in user 
requests is key to the conflict resolution strategy and speed. (See 
Bibliography for reference on statistical results for the three scheduling 
architectures tested.) 

Managing Temporal Relations in MAESTRO , Dan Britt, Martin Marietta 

This presentation outlined the scheduling approach used by MAESTRO. 
This approach represents all available domain information to the 
scheduling system, including knowledge of activity structures, temporal 
constraints, resource types, use functions and availabilities, preferences in 
activity placement, resource use, schedule evaluation criteria and ways 
contingencies occur and are resolved computations are then performed to 
analyze and synthesize information. The domain and synthesized 
information is used to incrementally reduce the schedule search space for 
acceptable/good schedules. The majority of the search space is reduced 
implicitly by not allowing representable constraint violations. 

MAESTRO, uses an opportunity algorithm for request placement. 

Temporal constraint propagation techniques specify acceptable time 
windows, and user specified criteria indicating importance of various 
heuristics are used for activity selection. An activity is defined as a 
sequence of subtasks, which accomplish goal(s). Each activity has 
associated resource, conditions, state, and timing requirements. 

Scheduling is defined as the start and end times for subtasks and their 
allocated resources. 

Four types of temporal relations were described. The first was constraints 
on the placement of a single activity, (constraints include resources, 
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conditions, time windows, activities of variable durations and delays, and 
relations of subtasks. The second temporal relation is the constraints 
between activities (e.g., precedes, follows, starts, one-way vs two-way 
constraints, relations to absolute times). The third relation is soft 
constraints representing general preferences (e.g., durations and delays), 
specific preferences (associate with a specific subtask, event or time), 
random placement and user placement. The last relation is contingency 
handling of late requests, bumping to fit new requests, and interrupting 
and restructuring an activity in real time. 

Resource Repre sentation in COMPASS . Barry Fox, MacDonnell Douglas 

The COMPuter Aided Scheduling System (COMPASS) was developed for 
NASA to evaluate AI and advanced scheduling technology. It is written in 
Ada with an X-windows user interface. It is incremental, that is activities 
are added one at a time on a timeline, with knowledge of existing activities 
and resources. COMPASS is also interactive, with selection and placement 
°f activities specified by user controlled commands. The order of adding 
activities and their location are independent. 

In COMPASS, an activity is scheduled only if all required resources are 
available for the duration requested. The scheduling algorithm places 
activities on the timeline so that resource totals are not exceeded. 

Interactive and automated subsystems support both internal and external 
(textual) representations of resource requirements and availability. 

COMPASS represents resource requirements by piecewise linear functions, 
where the origin is relative to the beginning of the activity. An activity may 
be a consumer or producer of resources. Positive quantities represent 
amounts required and negative quantities represent the amount provided 
by an activity. Activities are represented as ordered list of segment 
descriptors and linked lists using the Ada generic list package. Object- 
oriented dotted notation is used (e.g., crew. ss. bob and crew.ss.alice can be 
selected by specifying crew.ss or just crew) and special notations for time 
are also featured. 

The placement algorithm locates a time where the activity's resources can 
be satisfied and subtracts those resources from the availability function. 
Unscheduling is performed by adding resources back. Since resource 
availability is also represented by piecewise linear functions, placing 
activities on the timeline is performed in segments. 

One of COMPASS s key features is that it was developed as an open system. 
Hence full source code and complete documentation are available, 
enhancing its reusability. 
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2.3.2 Session 3 Working Group Notes 


The groups were asked to identify key performance parameters from the 
viewpoints of the user POCC, SNC operations, schedule efficiency, and 
system development. User POCC and SNC operations comments relate to 
the process implemented for generating schedules, whereas schedule 
efficiency relates to the schedule as a product. Comments on applications 
of artificial intelligence and other techniques, as well as risk areas, were 
also solicited. 

The following discussion topics and instructions were provided. 

Session 3. Resource Allocation Tools, Technology, and Algorithms 

1. Identify at least 3 key performance parameters for the following 
viewpoints: 

a) User POCC 

b) SNC operability 

c) SN schedule efficiency 

d) System implementation 

Include a sentence or two, as needed, to explain/clarify each 
parameter. 

2. Select at least 3 of the performance drivers above and suggest ways 
of satisfying them. Address application of AI and other techniques 
and identify risk areas. 

3. Identify candidate SN resource allocation prototyping objectives. 
Provide rationale. 

Performance drivers for the SNC are summarized in the next four 
sections, followed by a section on recommendations for prototyping. 


2.3.2. 1 User POCC Accountability 

The following metrics are recommended for accountability to users: 

• Number and percent of requests scheduled according to user-defined 
priorities and mission goals 

• Requests altered with rationale 

• Requests rejected with rationale 

• Response time for initial scheduling from requests 

• Response time for scheduling change requests 

• Response time for near real-time changes 
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• Lead time required by SNC for submitting requests 

• Lead time needed to develop requests 

Common tools for easy user access to scheduling information and 
communications with SNC are recommended. Suggestions for scheduling 
information to be provided to the users include: 

• Intermediate feedback on ongoing processes 

• Routine feedback on how well SNC is working (automated statistics) 

• Long term loading analysis (identify busy weeks) 

• Notification of opened slots, available resources 

Other SNC supplied user assistance is recommended as follows: 

• Staff a help desk 

• Educate users on scheduling options and ways to optimize requests 

• Provide adequate visibility into the scheduling process 

• Identify level of risk associated with particular events 

• Provide tools for learning and using a flexible request language 

Several user POCC concerns which affect scheduling performance were 
discussed. For example, the compatibility of the SN scheduling process 
with the user’s mission goals and the reliability of the schedule 
commitment from the SNC (i.e., the stability of the published schedule) 
were raised as issues. There was also a concern that automated tools may 
allow their users to acquire more resources than users with manual 
methods. 


2.3.2.2 SNC Operability 

The following metrics (in addition to those mentioned above for user 
POCCs) are recommended for SNC operations accountability: 

• Time to generate schedule/update schedule 

• Ratio of the time to generate (runtime and wall clock-time) to the length 
of the schedule (e.g., should require hours or less to generate a week long 
schedule) 

• Interactive system response time (e.g., HCI updates, graphics, etc.) 

• System response time during high interaction (e.g., conflict resolution) 

• Number of iterations between subsystems 

• Number/type of interactions with users 

• Downtime for maintenance (tools provided) 

• Percent of operator's time required for normal operations 

• Quality of operator attention/skill needed 

Suggested parameters for assessing ease of use and operations costs are: 

• Number of operators required 

• Time to train, tools for training 
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• Skill level required 

• Number/type of errors made 

• Level of assistance system provides 

• Forgiving system response to operator input errors (undo) 

• Automatic high level checks on operator inputs 

• Use of standard interfaces and procedures 

Robust operations are dependent on the ability to do the following: 

• Accommodate change in SN (e.g., new ground terminals, new users) 

• React to critical events (regenerate/disseminate schedule) 

• Meet users need in event of launch slip 

• Create and maintain multiple schedules 

Possible uses of SNC accounting statistics are to monitor operations, 
manage trends and adjust priorities, assess success in meeting mission 
SIRD (i.e., compare actual support to negotiated support), and to provide 
feedback to users. 


2.3.2.3 SN Schedule Efficiency 

The following metrics for assessing scheduling efficiency are suggested: 

• Resource utilization (level usage distribution) 

• Percent of un-allocated resources, noting utility (e.g., fragmented or not) 

• Number of events scheduled per time increment 

• Number of conflicts and ease of resolution 

• Number of events affected by contingency, duration of time affected by 
ripple (resiliency) 

• Resource allocation data to monitor trends, determine if the SN is 
oversubscribed 

How to measure user satisfaction with the resultant schedule is a difficult 
question, but some insight into the quality of the schedule can be assessed 
by the following: 

• Percent of requests satisfied (total and by mission, during forecast and 
active period in, preferred and degraded service modes) 

• Difference between user's requests and actual resource utilization 

Several areas of concern include understanding and minimizing the 
impact of the rescheduling process on the schedule handling peak service 
loads, and responding to contingencies. There was a suggestion to define 
metrics for responses and to model contingencies. A cost/benefits trade 
analysis of optimization techniques is needed. Regarding optimization, no 
system totally optimizes a schedule, rather systems evaluate alternatives 
and pick the best schedule from among those alternatives. 
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2.3.2 A System Implementation 

The recommended system development and performance factors to monitor 
include: 

• Time and cost (source lines of code productivity measure); 

• Maintainability; 

• Tradeoff between flexibility and complexity; 

• Time to implement a new function; 

• Time to upgrade or port to a new platform; 

• Test time needed (benchmark set of requests should be provided for 
testing); 

• Percent commercial off-the-shelf components; 

• Computer processing time to generate schedule (CPU utilization); 

• Message latency; 

• HCI response time. 

Adequate development resources, in terms of time, funds, equipment and 
tools (development environment) are needed to increase productivity and 
maintain an audit trail. These requirements are especially important for 
building an extensible and adaptable system. The use of standards 
(especially interface standards) and common, modular (table driven) 
components is recommended to allow components to be added, upgraded, 
and automated by modifying algorithms, resetting parameters, and 
replacing modules. 


2.3.2.5 Prototyping 

Suggested prototyping goals are to validate operations concepts, involve 
users (schedule operators and POCC users), inject innovation, guide the 
level of automation, mitigate risks, and capture lessons learned (i.e., the 
problems and successes of NCC and prototypes). 

Suggested prototype approaches include introducing the SNC scheduler 
prototype in a "shadow mode". By using the prototype as a scheduling 
advisor system, the operator would gain confidence in the new technology. 
Off-the-shelf components should be considered for prototype development. 
Finally, successful prototypes developed before the SNC contract award 
could be provided as government furnished equipment. 

Potential activities for prototyping are categorized into six areas: studies, 
operations concept, user POCC needs, flexible request language; scheduler 
interface; and scheduling techniques. 
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Studies 

• Survey technology developments, determine unique features of each and 
their applicability to SNC. 

• Measure performance characteristics, such as manhours to generate a 
schedule in the NCC, as a baseline to compare with prototypes. 

• Define the "goodness” of a schedule. Suggested parameters are the 
percent of SN resources used, the total number user requests satisfied, the 
percent of each user's requests satisfied, and the amount of science return, 
among others. 

Operations Concents 

• Base the prototype implementation on an operations concept, not vice 
versa, and validate the concepts. 

• Generate multiple operations scenarios including nominal operations, 
spacecraft emergency, ATDRSS outage, and Shuttle launch slips. 

• Show the feasibility of generating alternate schedules (e.g., for Shuttle 
slips). 

• Compare timeline processes of scheduling/editing/rescheduling vs 
interactive scheduling. 

User POCC Needs 

• Identify user information needs; consider schedule visibility and security 
needs. 

• Identify mission critical and fast reaction functions. 

• Evaluate different priority schemes and their effects on meeting user 
goals and SNC commitments (stated in SIRD). 

• Investigate how scheduling goals may differ in forecast vs active periods. 
Flexible Request Language 

• Determine information flow between the SNC and user POCC interface 
for schedule generation through execution. Address the balance between 
flexibility and complexity. 

• Verify the flexible request language approach (benefits vs complexity). 
Note experience in MO&DSD Scheduling Concepts, Architectures and 
Networks (SCAN) testbed which implemented the FERN flexible request 
language, for instrument scheduling. 
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Scheduler Interface 


• Evaluate information coding with color, patterns and text (consider 
MO&DSD ground network scheduling system, CAIRS, for method of 
naming events). 

• Consider a "graphical phone call" technique, which allows the POCC 
and SNC to view the same information in resolving conflicts. 

Scheduling Techniques 

• Prove feasibility of scheduler extensibility approach (end-to-end 
prototyping of modular elements). 

• Identify the best algorithms. Note MO&DSD algorithm evaluation tasks 
in support of the NCC. 

• Investigate AI approaches such as Stanford Telecom's LA-2D algorithm, 
A* algorithm, and/or the use of schedule quality metrics as search drivers. 
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Section 3 — Conclusions 

The SNC Conference on Resource Allocation Concepts and Approaches 
proved to be a fruitful forum for suggesting ideas and discussing issues for 
the SNC. The three items summarized below capture the main themes of 
the conference. 


3. 1 Key Recommendations 

• Management criteria for success - The quality of a schedule tends to be in 
the eye of the beholder. To alleviate perception problems with SNC 
produced schedules, it is recommended that specific measures of schedule 
quality be routinely evaluated and provided to the users. An online 
automated accounting capability is recommended to maintain statistics on 
resource utilization, request disposition and turnaround time, and 
schedule generation and update time. 

• Level of automation - A more automated decision support system is 
recommended for SNC. Automated tools are needed to aid human 
operations, incorporating improved human-computer interface techniques 
which support the interpretation of data and the direct manipulation of 
interface functions. 

• New SNC - User POCC interface - A flexible scheduling request language 
for specifying SN service requests is recommended. Both specific requests 
(e.g., data in a Schedule Add Request) and flexible requests (e.g., a single 
request for a routine repetitive return service for at least 10 minutes every 
orbit) need to be supported. The concept implies that access to scheduling 
information, such as orbital data for user antenna view periods, will be 
available to the SNC. An SNC help desk and modular tools should be 
provided to the user POCC to ease the implementation of a new interface. 


3.2 Concerns 

Concerns such as developing the SNC to accommodate changes in the SN, 
system engineering in a distributed environment, and security issues were 
raised. In addition, risks related to the key recommendations were 
addressed and are summarized below. 

• Level of automation - A key question for the system definition phase is 
whether the SNC is automated with full operator visibility for manual 
override, or if it supports human decision making with automated tools. 
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• Scheduler performance - Another key risk area is scheduler 
performance, measured by 1) the time to generate a schedule, 2) meeting 
scheduling goals set by management, and 3) schedule resiliency (i.e., the 
ability to minimize disturbance to the overall schedule due to rescheduling 
activities). 

• Flexible requests - A trade off between the degree of flexibility sufficient 
for SN scheduling and the complexity of the SNC and user POCC interface 
must be assessed. Assuring efficient use of resources (e.g., avoiding 
overscheduling) and minimizing the impact of a new user interface on 
existing missions are also concerns. 

• Access to scheduling data - Scheduling information needed to interpret 
constraints comes from many sources, including the SN elements, Flight 
Dynamics, and the POCCs. Determining who has responsibility for 
providing scheduling data access and maintenance is a systems 
engineering issue. 


3.3 Prototyping 

Throughout the conference, prototyping was continually mentioned as an 
effective mechanism for verifying operations concepts and evaluating 
specific technology risks. Rapid prototypes can be used to illustrate 
operations concepts, and more detailed prototypes may implement a subset 
of SNC functions for a proof of concept or for performance evaluation (e.g., a 
scheduling engine prototype). Modelling and human factors task analyses 
are also recommended. 

Goals for SNC prototyping are to involve users, both from the POCCs and 
from SNC operations, in evaluating automation approaches, in assessing 
innovation and risk areas, and in capturing lessons learned for the SNC. 
Operations scenarios are needed to define both nominal schedule 
generation as well as non-nominal situations (e.g., rescheduling for 
emergencies, equipment outages, Shuttle launch slips). 

Two key activities recommended for evaluation address the scheduling 
timeline. Alternatives for schedule generation need to be investigated to 
compare batch processing (e.g., forecast/active periods) versus continual 
incrementally updated schedule processing. The concepts of parallel 
alternative schedule generation and wait lists for contingency planning 
need to be investigated by prototyping. 

Many of the recommendations are being pursued or investigated in the 
various SNC development tasks. A prototyping effort for SNC is underway 
to address as many of the suggested topics as time and funding will 
support. An initial testbed is planned to be established by the end of FY91 
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and will include an SNC scheduling prototype and a user POCC 
workstation interface. The testbed operations scenario will demonstrate the 
use of a flexible scheduling request language and operator tools for 
generating and maintaining an SN schedule. Those involved in the SNC 
development will continue to seek input and guidance from individuals and 
institutions involved in SN scheduling. 
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SPACE NETWORK CONTROL CONFERENCE ON RESOURCE ALLOCATION 
CONCEPTS AND APPROACHES 

DECEMBER 12 - 13, 1990 
WORKING GROUP DISCUSSION QUESTIONS 


SUGGESTION: 

Keep a running list of concepts/issues that may be considered for SNC as you listen to the 
briefing. 

Examples: 

• Distributed systems and information access 

• Locus of control 

• Level of automation 

• Timeline management 

• Generic scheduling 

• Impact of demand access 

• Impact of “classes” of users on scheduling services 


SESSION 1. CONCEPTS FOR SPACE NETWORK RESOURCE ALLOCATION 

1. Identify the three most critical issues for Space Network Resource Allocation In terms of: 

a. Management 

b. Operations 

c. SN User POCCs 

d. System Development 

Include a sentence or two, as needed, to explain/clarify each issue. 

2. Select at least three of the critical issue above and suggest ways of resolving them. 
Address innovation and risk factors. Identify areas for further study and suggest study 
approaches. 

3. Discuss how resource allocation might be performed for: 

a. Rescheduling In the event of a failure to the ATDRSS Ground Terminal. 

b. Scheduling of previously allocated resources that unexpectedly become available 
(e.g., shuttle launch slips). 

4 . Discuss the pros and cons of dividing the schedule timeline Into forecast (batch) and 
active (Incremental updates) periods. Suggest alternative schedule timeline approaches tor 
SNC consideration. 

5. Given that there are different user classes, discuss the pros and cons of subdividing 
available resources Into multiple subnetworks based on user classes and demands for use by 
each user class. 
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SESSION 2. 


SNC AND USER POCC HUMAN-COMPUTER INTERFACE 
CONCEPTS. 


1. Using presentation materials as a baseline, provide a definition of "generic scheduling' 
and make recommendations for Its use In terms of concept, requirements, and Implementation 
a n d f p* o vl d e° rations [ £ C e ° , v e s ,0 make 9 enerlc scheduling an attractive option for user POCCs 

2. Discuss the pros and cons of redefining the user POCC scheduling interface In 

conjunction with defining the SNC scheduling interface to the POCCs. Address the potential for 
providing common tools for user POCCs. K 

3. Scheduling system user Interfaces guidelines are not mature today and standards are not 

,oreseeabl ® future. Suggest steps that should be taken to Incorporate human 

AHrt° S 9u,d 1 f lines ,or ,h ® human computer Interface into the system development process. 
AuQieSs risk areas. 

4 Suggest an approach and discuss trade-offs for determining appropriate levels of 
automation for the SNC, for example, fully automated operations, human management by 

exception (supervisor role), human activated with computer assistance (computer recommends 
actions), or manual operations. H rctummenas 


SESSION 3. RESOURCE ALLOCATION TOOLS, TECHNOLOGY, AND ALGORITHMS 

1 . Identify at least three key performance parameters for the following viewpoints: 

a. User POCC 

b. SNC operability 

c. SN schedule efficiency 

d. System implementation 

Include a sentence or two, as needed, to explaln/clarlfy each parameter. 

2. Select at least three of the performance drivers above and suggest ways of satisfying 
them. Address application of Al and other techniques and risk areas. 

3. Identify candidate SN resource allocation prototyping objectives. Provide rationale. 
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MO ADS 
DIRECTORATE 


SPACE NETWORK CONTROL (SNC) 
CONFERENCE ON 

RESOURCE ALLOCATION CONCEPTS AND APPROACHES 


°&lv 


SURVEY EXISTING RESOURCE ALLOCATION CONCEPTS AND APPROACHES. 

IDENTIFY SOLUTIONS APPLICABLE TO THE SN PROBLEM. 

IDENTIFY FRUITFUL AVENUES OF INVESTIGATION IN SUPPORT OF SNC 
DEVELOPMENT. 

CAPTURE KNOWLEDGE IN PROCEEDINGS AND MAKE AVAILBLE TO BIDDERS 
ON THE SNC CONCEPT DEFINITION PROCUREMENT. 
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MO&DS 

DIRECTORATE 


CODE 500 


SPACE NETWORK CONTROL (SNC) 
CONFERENCE ON 

RESOURCE ALLOCATION CONCEPTS AND APPROACHES 




THE CURRENT NCC WORKS, PROVIDING A VARIETY OF SCHEDULING AND 
TECHNICAL MANAGEMENT FUNCTIONS FOR THE SPACE NETWORK (TDRSS), 
THE GROUND NETWORK (MIL.BDA, DKR) AND INTERFACE TO OTHER 
NETWORKS (DSN, RTS) 

THE SPACE NETWORK IS CHANGING: 

TDRS CLUSTER ARCHITECTURES 
WHITE SANDS GROUND TERMINAL COMPLEX 
NEW ATDRSS SERVICES 
MIXED FLEET TDRS/ATDRS 

INTERNATIONAL DATA RELAY SATELLITE INTEROPERABILITY 

AS THESE CHANGES PROGRESS. THE CURRENT NCC SYSTEM AND SOFTWARE 
ARCHITECTURE BECOMES INCREASINGLY DIFFICULT TO MAINTAIN. 


MO&OS 

DIRECTORATE 


CODE 500 


SPACE NETWORK CONTROL (SNC) 
CONFERENCE ON 

RESOURCE ALLOCATION CONCEPTS AND APPROACHES 





1 DEVELOP A SYSTEM ARCHITECTURE CAPABLE OF ACCOMMODATING CHANGE 

HARDWARE 
SOFTWARE 
INTERFACES 
SPAN OF CONTROL 

2. IMPROVE SN USER SATISFACTION 

SN USER INTERFACE - VARYING LEVELS OF USER SOPHISTICATION & NEED 
% OF SUPPORT REQUESTS GRANTED - A SCHEDULING ISSUE 

3. IMPROVE THE SN INSTITUTIONAL UTILIZATION AND EFFECTIVENESS 

SNC LIFE CYCLE COSTS: OPERATIONS AND SYSTEM MAINTENANCE 
INCREASE THE UTILIZATION OF THE SN 


5% INCREASE MAY SAVE THE COST OF AN ATDRS OVER THE 15 YEAR 
PROGRAM LIFE CYCLE ($200M - $300M) 

THIS IS BOTH A SCHEDULING AND SYSTEM RELIABILITY ISSUE 
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MO&D3 

DIRECTORATE 


CODE 500 


SPACE NETWORK CONTROL (SNC) 
CONFERENCE ON 

RESOURCE ALLOCATION CONCEPTS AND APPROACHES 

INTRODUCTION 



BACKGROUND 


• THE CURRENT NCC WORKS, PROVIDING A VARIETY OF SCHEDULING AND 
TECHNICAL MANAGEMENT FUNCTIONS FOR THE SPACE NETWORK (TDRSS). 
THE GROUND NETWORK (MIL.BDA, DKR) AND INTERFACE TO OTHER 
NETWORKS (DSN, RTS) 

• THE SPACE NETWORK IS CHANGING: 

TDRS CLUSTER ARCHITECTURES 
WHITE SANDS GROUND TERMINAL COMPLEX 
NEW ATDRSS SERVICES 
MIXED FLEET TDRS/ATDRS 

INTERNATIONAL DATA RELAY SATELLITE INTEROPERABILITY 

AS THESE CHANGES PROGRESS. THE CURRENT NCC SYSTEM AND SOFTWARE 
ARCHITECTURE BECOMES INCREASINGLY DIFFICULT TO MAINTAIN. 
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CODE 500 


SPACE NETWORK CONTROL (SNC) 
CONFERENCE ON 

RESOURCE ALLOCATION CONCEPTS AND APPROACHES 
INTRODUCTION 



GOALS FOR SPACE NETWORK CONTROL 


1 . DEVELOP A SYSTEM ARCHITECTURE CAPABLE OF ACCOMMODATING CHANGE 

HARDWARE 
SOFTWARE 
INTERFACES 
SPAN OF CONTROL 

2. IMPROVE SN USER SATISFACTION 

SN USER INTERFACE - VARYING LEVELS OF USER SOPHISTICATION & NEED 
% OF SUPPORT REQUESTS GRANTED - A SCHEDULING ISSUE 

3. IMPROVE THE SN INSTITUTIONAL UTILIZATION AND EFFECTIVENESS 

SNC LIFE CYCLE COSTS: OPERATIONS AND SYSTEM MAINTENANCE 
INCREASE THE UTILIZATION OF THE SN 

5% INCREASE MAY SAVE THE COST OF AN ATDRS OVER THE 1 5 YEAR 
PROGRAM LIFE CYCLE ($200M - $300M) 

THIS IS BOTH A SCHEDULING AND SYSTEM RELIABILITY ISSUE 
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MOADS 

DIRECTORATE 


CODE 500 



SNC Conference 
on 

Resource Allocation Concepts 
and Approaches 


Conference Format 


December 12, 1990 


SNC Conference Format 


Conference Format 


K. Moe/522 


gSf c 



Conference Introduction 

Session 1 : Concepts for SN Resource Allocation 

Session 2: SNC and User POCC Human-Computer Interface Concepts 

Session 3: Resource Allocation Tools, Technology, and Algorithms 

Working group discussions will follow each session 

Each presentation will be approximately 20 minutes 

Conference proceedings will be published early in 1991 and will contain: 

Presentation Slides/Presentation Papers 
Working Group Results 


6 -? 
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MOWS 

DIRECTORATE 


CODE 500 


SNC Conference Format 


Working Group Discussions 



Working groups will consist of: 

Leader 

Recorder 

Approximately 8 members total 

Working groups will address specific "questions to be answered" in the 
conference handout 

Leader and Recorder will be responsible for the documentation of working 
group efforts 

Everyone is encouraged to take notes during presentations to capture ideas 

Your participation and contributions to working group discussions are 
essential elements of this conference 



MOWS 

DIRECTORATE 


CODE 500 


SNC Conference Format 


Working Group Discussions (Cont’d 


Working Group Leaders 

Dorthy Perkins 
Pepper Hartley 
Philip Liebrecht 
Candace Carlisle 
Vern Hall 
Doug McNulty 
BJ Hayden 

Working Group Recorders 
Eric Richmond 

Beth Antonopulos/Brian Dealy 

Lisa Karr 

Bill Potter 

Nancy Goodman 

Ken Johnson 

Karen Thorn 



B-4 
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December 12, 1990 


8:00 - 8:30 Registration 

8:30 - 9:30 Conference Introduction 

9:30- 11:15 Session 1 : Concepts for SN Resource Allocation 
11:15 - 12:15 Lunch 

12:15- 1:00 Session 1 (Cont’d) 

1 :00 - 3:30 Session 1 Working Group Discussions 

3.30 - 5.00 Session 2: SNC and User POCC Human-Computer Interface 

Concepts 

December 13, 1990 

9:15 Session 2 (Cont'd) 

11:15 Session 2 Working Group Discussions 

12:15 Lunch 

3:15 Session 3: Resource Allocation Tools, Technology, and 
Algorithms 

5:00 Session 3 Working Group Discussions 
Concluding Remarks 


8:00 - 
9:15 - 
11:15 - 
12:15 - 

3:15 - 
5:00 


B-S 
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SCHEDULING OVERVIEW 
AND 

CHALLENGES 

NOVEMBER 1990 

A. LEVINE 
CODE 534.2 


MO&DS 

DIRECTORATE 

CODE 500 


SCHEDULING OVERVIEW AND CHALLENGES 

INTRODUCTION 



• THE NCC IS RESPONSIBLE FOR THE ALLOCATION 
OF SPACE NETWORK RESOURCES TO MEET 
AUTHORIZED USER REQUIREMENTS. 

- SCHEDULES TDRS AND WSGT 

- SCHEDULES NASCOM 

- SCHEDULES NASA GROUND TERMINAL 

- SCHEDULES SDPF 


C-2 
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MO&DS 

DIRECTORATE 


CODE 500 


SCHEDULING OVERVIEW AND CHALLENGES G 


sJLc 


SCHEDULING PROCESS 


POCC 

OPERATOR 


— — VOICE COMMUNICATION — — 


/ SCHEDULING \ 
\ OPERATOR 1 


POCC 


SCHEDULE 

BARi 

GENERATION 

M00 BfT ILOCK 

OR MPT 
1 


SCHCDtAf RESULT MESSAGES (ACCE PT /REJECT) 


FORECAST 

QUEUE 

SCHEDULE 

PROCESSOR 

SCHEDULED 

EVENTS 

STORAGE 

BUFFER 


HARDCOPY 

LISTINGS 

ALL 

SUBMITTED 

SARs 


REJECTS ARE COORDINATED VERBALLY 
FOR CONaiCT RESOLUTION 

UPON AGREEMENT OF AVAILABLE TIME 
SLOT/RESOURCES. THE USER TRANSMITS 
A NEW SAR OF NCC MOOIF1ES ORDINAL. 


REJECTED 

SARs 

SCHEDULED 
EVENTS 
LISTING (AT 
OPTION OF 
SO) 


MO&DS 

DIRECTORATE 

CODE 500 


SCHEDULING OVERVIEW AND CHALLENGES V . 

SCHEDULING TIMELINE 


FOREC AST SCHE DULING 
PERIOD 


ACTIVE SCHEDULING PERIOD 


mtwtfssmtwtfss M 


T W T F S 


THE FORECAST ANALYST * 

WILL GENERATE A 
WEEKLY SCHEDULE FROM 
POCC SAR'S 

CONFLICT RESOLUTION IS 
DONE BETWEEN THE POCC 
AND FORECAST ANALYST 

THE NCC BEGINS ACCEPTING 
THE TRANSMISSION OF 
THE POCC'S SAR S FOR 
THE FORECAST WEEK ON MONDAY. 

U DAYS IN ADVANCE OF THE 
BEGINNING OF THE FORECAST 
PERIOD. 

AFTER ALL POSSIBLE CONFLICTS HAVE BEEN 

RESOLVED. THE NCC ACTIVATES THE FORECAST 

SCHEDULE THIS RESULTS IN THE AUTOMATIC 
TRANSMISSION OF REJECT MESSAGES FOR ANY REQUESTS 
THAT COULD NOT BE SCHEDULED THE NCC THEN 
TRANSMITS THE CONFIRMED SCHEDULE FOR THE FORECAST 
WEEK TO THE USER POCC*S. 


SCHEDULE 

WEEK 

(OOOOOOZ Monday lo 
235959Z on Sunday) 


• THE POCC MAY BEGIN 
SUBMfTTING UPDATES FOR THE 
PERIOD JUST ADDED TO THE 
ACTIVE PERIOD. {UPDATES 
MAY BE SUBMITTED ANYTIME UP TO 10 
MINUTES PRIOR TO EVENTS 
START TIME) 


DAILY EVENT TRANSMISSIONS 
000(H) 1 00 Z NGT DAILY 

0000-01002 WSGT DAILY FROM 1200-2359 FOR CURRENT DAY 
1200Z WSGT DAILY FROM 0000-1159 FOR UPCOMING DAY 
2200Z NASCOM/SDPF DAILY FOR UPCOMING DAY 
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MO&DS 


s Ac 


directorate SCHEDULING OVERVIEW AND CHALLENGES 

CODE 500 


NUMBER OF SN USERS 


MO&DS 

DIRECTORATE 

CODE 500 


sAc 


SCHEDULING OVERVIEW AND CHALLENGES G < ^^ * 


SN EVENTS PER DAY 

PEAK DAILY LOADING 
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MO&DS 

DIRECTORATE 


SCHEDULING OVERVIEW AND CHALLENGES 


CODE 500 


SCHEDULING CHALLENGES 


• CURRENT 

- EFFICIENT USE OF NETWORK RESOURCES 

- SCHEDULING SHUTTLE - MINIMIZE IMPACT ON 
OTHER USERS 

- USER POCC INTERFACE 

- REFINE FORECAST/ACTIVE PERIOD PROCEDURES 

- SCHEDULING AROUND RFI 

- BETTER TOOLS FOR CONFLICT RESOLUTION - 
EMPHASIS ON AIDING SCHEDULER, NOT 
REPLACE/AUTOMATE 
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MO&DS 


DIRECTORATE 
CODE 500 


SCHEDULING OVERVIEW AND CHALLENGES 



SCHEDULING CHALLENGES (CONTINUED) 

• FUTURE 

- SCHEDULING CONTROL - MAN AND MACHINE FUNCTIONS 

- GENERIC SCHEDULING - TAKE INITIATIVE, DON’T REACT 

- TRANSITION 

• TDRSS TO ATDRSS 

• NCC TO SNC 

- SSF SCHEDULING 

- INTERNATIONAL SPACE NETWORK INTEROPERABILITY 

- SPACECRAFT PROXIMITY OPERATIONS (E.G., SHUTTLE 
DELIVERY, SSF) 

- DEMAND ACCESS 


C-8 
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INCORPORATED 


N92- 11 041 


Presented to 

Symposium on Planning and Scheduling 


Prepared for 

Goddard Space Flight Center 
Mission Operations & Data Systems Directorate 
Code 520 

Prepared by 

NASA Programs Office 
CTA INCORPORATED 
6116 Executive Boulevard 
Rockville, Maryland 20852 


December 12, 1990 


n-i 


What We Were Asked to Do 

INCORPORATED 

• Document planning and scheduling lessons learned 

• Provide recommendations 

• Relate lessons learned to mission characteristics 
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What We Did 


INCORPORATED 

• Conducted, documented, and validated 32 interviews 

- Missions included were: COBE, ERBS, EP/EUVE, HST, LANDSAT SME 

SMM, STS 

- Institutional facilities included were: CMF, FDF, MSOCC, NASCOM, NCC 

- Persons interviewed included: Scientists, operations personnel, managers, 

software engineers 

• Identified lessons learned from raw data collected in interviews 

• Analyzed lessons learned across missions and facilities 

• Identified relevant mission characteristics and analyzed their relationships to the 
lessons learned 

• Developed/formulated recommendations that address the lessons learned perceived 
as having a major impact on the planning and scheduling process 


NASS 30680 
0-3 


INCORPORATED 


Major Recommendations 


• Operational concepts are introduced much too late in the mission cycle. 

1 . Develop end-to-end planning and scheduling operations concepts by 
mission class and ensure their consideration in system life cycle 
documentation. 
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INCORPORATED 


Background • Recommendation 1 


• Persons interviewed consistently expressed the need for considering operational 
implications early in mission life cycle 

• Systems Instrumentation Requirements Document (SIRD) frequently developed 
before the Mission Operations Concept Document 

• Detailed analysis of operational factors might have avoided subsequent planning 
and scheduling problems (e.g., inability of NCC to support cross-support 
required by HST) 


NAS 5 306K0 5 
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Details - Recommendation 1 

INCORPORATED 

• Develop mission operations concepts to include non nominal sequences 

• Develop guidelines/document outlines and timelines for system documentation 

• Require traceability between system documentation and the mission operations 
concept 
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Major Recommendations 


INCORPOK a I ED 


• The lack of an adequate end-to-end planning-and scheduling systems engineering 
approach has resulted in fragmentation in mission planning and scheduling. 

2 . Create an organizational infrastructure at the Code 500 level, supported 
by a Directorate-level steering committee with project representation, 
responsible for systems engineering of end-to-end planning and 
scheduling systems. 


NAS S 306KU 
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INCORPORATED 


Background - Recommendation 2 


• Planning and scheduling systems are developed in disjoint pieces 

• Excessive verbal communication and iteration are required to compensate for 
system engineering deficiencies 

• Fragmentation transcends MO&DSD to divisions, flight projects, and users 
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Details - Recommendation 2 


INCORPORATED 


• Include technical committee representing all divisions. Advanced Missions 
Analysis Office, and each project in the flight Projects Directorate 

• Analyze and coordinate technical decisions that transcend individual divisions 
within MO&DSD 

• Ensure that systems are specified and developed within the framework of an end- 
to-end information flow analysis 

• Support interactions with other organizations (e.g.. Flight Projects Directorate) 
concerning planning and scheduling implications of high level decisions (e.g., 
spacecraft design and operations concept) 

• Oversee development of a strategy for integration of all MO&DSD planning and 
scheduling elements 

• Ensure operational user evaluation 


NAS 5 306S0 
D-9 



INCORPORATED 


MajorJRecomn^ 


• Problems in mission planning and scheduling systems are exacerbated, but not 
created by, identifiable mission characteristics that are established in the Phase A 
timeframe of a mission's life cycle. 

3. Develop and refine mission modeling capabilities to assess impacts of 
early mission design decisions on planning and scheduling. 
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Bgckground_^^ecommendation 3 


INCORPORATED 


• Mission characteristics related to spacecraft design and the mission operations 
concept can exacerbate planning and scheduling problems 

• Discrepancies can exist between flight project and MO&DSD regarding expected 
availabilities and capabilities of institutional resources (e.g., TDRSS) 

• Difficulty in capturing and analyzing dynamic relationships using traditional 
methods for specifying operations concepts (e.g., text & block diagrams) 


NAS 5 30680 
D-ll 


INCORPORATED 


Details - Recommendation 3 


• Assess impacts of early mission design decisions on planning and scheduling, 
particularly space- to-ground communications requirements 

• Facilitate analysis of dynamic aspects of mission concept 

Support consistency and traceability between the Mission Operations Concept 
Document and subsequent specifications 
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INCORPORATED 


Major Recommendation 4 


• The current approach to scheduling, both within the NCC and in most missions, 
does not provide sufficient flexibility and is a major factor in the rescheduling 
problem. 

4. Emphasize operational flexibility in the development of the Advanced 
Space Network, other institutional resources, external (e.g., project) 
capabilities and resources, operational software and support tools. 


NAS 5 306K0 I 3 
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INCORPORATED 


Jjtackground^Jiecommend^ 


• Most planning and scheduling systems are designed to support a single operations 
concept 

• Difficulties arise when unanticipated events force a deviation from the nominal 
sequence 

• Variation in needs of missions are not accommodated in current systems (e.g., 
fixed NCC timeline) 
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INCORPORATED 


Details - Recommendation 4 


• Include service-level request disposition, extensible contacts, flexible timelines 

• Institutional resources (e.g., NASCOM, FDF) should accommodate nominal and 
non-nominal sequences of planning and scheduling activities 


NAS 5 30680 
D - 1 5 
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CONCEPTS, REQUIREMENTS, 

AND DESIGN APPROACHES 
FOR BUILDING SUCCESSFUL 
PLANNING AND SCHEDULING SYSTEMS 

PART I: A PROGRAMMATIC PERSPECTIVE 

RHODA SHALLER HORNSTEIN 

NASA / OFFICE OF SPACE OPERA TIONS 

PART II: A TECHNICAL PERSPECTIVE 

JOHNK. WILLOUGHBY 
INFORMATION SCIENCES, INC. 


SPACE NETWORK CONTROL CONFERENCE 
NASA / GSFC 


DECEMBER 12, 1990 

F- 1 


PRESENTATION OUTLINE 


-► PART I: A PROGRAMMA TIC PERSPECTIVE 

• STATING THE MANAGEMENT CHALLENGE 

• DISSECTING THE MANAGEMENT CHALLENGE 

• RESPONDING TO THE MANAGEMENT CHALLENGE 

• FOCUSING THE TECHNICAL PERSPECTIVE 

• SUMMARY 

PART II: A TECHNICAL PERSPECTIVE 

• REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 

• GOOD AND BAD STARTING POINTS FOR THE DESIGN 

• PROJECTING THE CONSEQUENCES OF OPERATIONS 
CONCEPTS 

• SUMMARY 
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STATING THE MANAGEMENT CHALLENGE 


HOW CAN THE TRADITIONAL PRACTICE OF 
SYSTEMS ENGINEERING MANAGEMENT, 
INCLUDING REQUIREMENTS SPECIFICATION, 

BE ADAPTED, ENHANCED, OR MODIFIED 
TO BUILD FUTURE PLANNING AND SCHEDULING SYSTEMS 
THAT POSSESS LIFECYCLE EFFECTIVENESS? 


r-3 
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DISSECTING THE MANAGEMENT CHALLENGE 


TRADITIONAL SYSTEMS ENGINEERING MANAGEMENT PROCESS 



E-4 
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DISSECTING THE MANAGEMENT CHALLENGE 


REDESIGNING THE SYSTEM BASED ON OPERATIONAL EXPERIENCE 



DISSECTING THE MANAGEMENT CHALLENGE 


PLANNING AND SCHEDULING SYSTEMS 


ANY HUMAN-COMPUTER DECISION-SUPPORT SYSTEM THAT DETERMINES 
AND / OR REDETERMINES HOW SHARED RESOURCES WILL BE MANAGED 
OVER TIME 


RESOUBCES 

ON-ORBIT 

SPACECRAFT 

PLATFORMS 

INSTRUMENTS 

EXPERIMENTS 

ASTRONAUTS 

LAUNCHES 

LAUNCH PADS 
LAUNCH VEHICLES 
PAYLOADS 

COMMUNICATIONS 


DECISIONS 

TO ASSURE ACCESS TO RESOURCES 

CONSISTENT WITH PROGRAM OBJECTIVES 

OBJECTIVES 

ACCURATE AND TIMELY ASSIGNMENTS <AND 
REASSIGNMENTS) OF RESOURCES 
IDENTIFICATION, AVOIDANCE, AND / OR 
RESOLUTION OF CONFLICTS 
EFFECTIVE AND COMPLEMENTARY HUMAN / 
COMPUTER INTERACTION 
UNCOMPLICATED AND STRAIGHT FORWARD 
HUMAN / HUMAN INTERFACE 


GROUND 

FACILITIES 

COMPUTERS 

ANTENNAS 

OPERATORS -6- 
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DISSECTING THE MANAGEMENT CHALLENGE 


SPACE OPERATIONS 



DISSECTIN G THE MANAGEMENT CHALLENGE 

LIFECYCLE EFFECTIVENESS 

OPERATIONAL EFFECTIVENESS 

DOING THE RIGHT JOB EFFICIENTLY 


EXTENSIBILITY 

EASY ACCOMMODATION OF CHANGE 
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RESPONDING TO THE MANAGEMENT CHALLENGE 

ADAPTATIONS TO THE TRADITIONAL PRACTICE OF 
SYSTEMS ENGINEERING MANAGEMENT 

FOR DOING THE RIGHT JOB EFFICIENTLY 

FOCUS SYSTEMS ENGINEERING EFFORT ON DEFINING AND BUILDING 
THE RIGHT SYSTEM, RATHER THAN ON DEFINING AND FOLLOWING THE 
RIGHT PROCESS 

KEY TO BUILDING THE RIGHT SYSTEM LIES IN DETERMINING AND 
IMPLEMENTING THE RIGHT REQUIREMENTS IN THE APPROPRIATE 
OPERATIONS CONTEXT 

10 ADAPTATIONS ARE RECOMMENDED 

FEATURED ARE: 

• REQUIREMENTS AND OPERATIONS CONCEPTS VALIDATION 

• PROTOTYPING 

• OPERATIONS CONSIDERATIONS AS EVALUATION CRITERIA 
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RESPONDING TO THE MANAGEMEN T CHALLENGE 

ADAPTATIONS FOR DOING THE RIGHT JOB EFFICIENTLY 

1. establish and maintain competing alternative operational concepts 

2. ADD OPERATIONAL EFFECTIVENESS CRITERIA TO THE EVALUATION PROCESS USED IN 
REQUIREMENTS AND DESIGN REVIEWS 

3. START WITH GENERAL FUNCTIONAL REQUIREMENTS AS A BASELINE 

4 ADD OPERATIONAL EFFECTIVENESS TO CRITERIA FOR DESIGN ACCEPTABILITY 

5. UTILIZE FORMAL PROTOTYPING PLAN FOR CONTROL DURING SYSTEM DEVELOPMENT 

6. USE WORKING SOFTWARE AS DETAILED DESIGN DOCUMENTATION 

7. DEVELOP A TECHNIQUE FOR MAKING DECISIONS TO BORROW TOOLS, APPROACHES, OH 
SOFTWARE VS. BUILDING TOOLS, APPROACHES, OR SOFTWARE 

8. ENFORCE AN END-TO-END IMPLEMENTATION STRATEGY - IMPLEMENT IN LAYERS NOT 
SEGMENTS 

9 FORMALLY ESTABLISH OPERATIONAL EFFECTIVENESS AS A TEST CRITERION 

10 DEVISE TEST PLANS WHICH CERTIFY OPERATIONAL EFFECTIVENESS IN REAL OR 
SIMULATED OPERATIONAL ENVIRONMENTS 
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RESPONDING TO THE MANAGEMENT CHALLENGE 


ADAPTATIONS TO THE TRADITIONAL PRACTICE OF 
SYSTEMS ENGINEERING MANAGEMENT 

FOR EASY ACCOMMODATION OF CHANGE 


ELEVATE REQUIREMENTS SPECIFICATION FROM INDIVIDUAL SYSTEM 
LEVEL TO CLASS LEVEL 


• REQUIREMENTS AT THIS LEVEL CAN BE PRECISE AND UNAMBIGUOUS 

• GENERAL ARCHITECTURE EXISTS AT THIS LEVEL TO INCORPORATE 
NEW REQUIREMENTS 


RECOGNIZE GENERAL CASE / SPECIAL CASE RELATIONSHIPS AND 
DESIGN FOR GENERAL CASE 

5 ADAPTATIONS ARE RECOMMENDED 


RESPONDING TO THE MANAGEMENT CHALLENGE 

REQUIREMENTS SPECIFIED AT THE CLASS LEVEL 


SOME REQ'MTS 
AT THIS LEVEL 
MAYBE: 

• INCOMPLETE 

• AMBIGUOUS 

• UNQUANTIFIABLE 

• DYNAMIC 



REQ’MTS AT 
THIS LEVEL CAN BE: 

• COMPLETE 

• UNAMBIGUOUS 

• MEASURABLE 

• STATIC 


E - 12 


74 


- 12 - 




RESPONDING TO THE MANAGEMENT CHALLENGE 


REQUIREMENTS NEED TO BE ELEVATED 

TRANSITION TO A GENERALIZED DESCRIPTION OF PLANNING AND SCHEDULING 




. CREWTIME, POWER, WATER 
• EXPERIMENT PERFORMANCE 
. SLEEP/ EAT CYCLES 


OMWOEXJML SVSYUi) 
LEVEL 


m 


. RESOURCES 
. ACTIVITIES 

. GENERAL TEMPORAL RELATIONS 


IPLMHM© & @©ME(D(yiLDN® 
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RESPONDING TO THE MANAGEMENT CHALLENGE 

ADAPTATIONS FOR EASY ACCOMMODATION OF CHANGE 

1. CHOOSE TOOLS THAT ARE DATA AND RULE-DRIVEN 

2. INCLUDE CODE STRUCTURE ASSESSMENTS AS A FORMAL PART 
OF DESIGN REVIEWS - FIND MODULES WITH SIMILAR 
FUNCTIONALITY AND GENERALIZE TO ELIMINATE "DUPLICATES" 

3. REVIEW DESIGNS FOR INTERPRETATIONS OF REQUIREMENTS 
THAT UNNECESSARILY LIMIT ENHANCEMENTS OR EXTENSIONS 


4. PERMIT MACHINE DEPENDENCY ONLY WHEN STRONGLY JUSTIFIED 


5. DEVELOP AN EVOLUTIONARY ACQUISITION STRATEGY DESIGNED 
FOR MULTIPLE CYCLES OF DESIGN AND IMPLEMENTATION 
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RESPONDING TO THE MANAGEMENT CHALLENGE 

RETROSPECTIVE ASSESSMENT OF HOW ADAPTATIONS WERE UTILIZED 






1 

COMPETING OPS CONCEPTS 

O 

UNK 

• 

2 

USE OF GENERAL REQUIREMENTS 

© 

0 

© 

3 

OPS EFFECTIVENESS CRITERIA IN SRR 

• 

UNK 

© 

4 

OPS EFFECTIVENESS CRITERIA IN PDR, CDR 

• 

UNK 

© 

5 

PROTOTYPING PLAN 

© 

0 

• 

6 

WORKING SOFTWARE AS SPECIFICATION 

• 

UNK 

© 

7 

BUILD v* BORROW CRITERIA 

o 

UNK 

© 

8 

END-TO-END IMP STRATEGY 

• 

0 

• 

9 

OPS EFFECTIVENESS AS TEST CRITERIA 

• 

UNK 

O 

10 

TEST IN OPERATIONAL ENVIRONMENT 

• 

0 

• 





1 

DATA- AND RULE DRIVEN 

• 

0 

• 

2 

CODE STRUCTURE ASSESSMENTS 

• 

UNK 

• 

3 

PERFORMANCE LIMITATION REVIEWS 

• 

0 

• 

4 

MACHINE INDEPENDENCE 

© 

0 

© 

5 

EVOLUTIONARY ACQUISITION 

• 

0 

• 


KEY 0 USED © PARTIALLY USED Q NOT USED 


EVALUATION BASED ON OPERATIONAL EFFECTIVENESS HIGH MODERATE HIGH 

EVALUATION SYSTEM BASED ON EXTENSIBILITY HIGH LOW HIGH -15* 
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FOCUSING THE TECHNICAL PERSPECTIVE 

ADAPTATIONS FOR DOING THE RIGHT JOB EFFICIENTLY 



2. ADD OPERATIONAL EFFECTIVENESS CRITERIA TO THE EVALUATION PROCESS USED IN 
REQUIREMENTS AND DESIGN REVIEWS 










4. ADD OPERATIONAL EFFECTIVENESS TO CRITERIA FOR DESIGN ACCEPTABILITY 

5. UTILIZE FORMAL PROTOTYPING PLAN FOR CONTROL DURING SYSTEM DEVELOPMENT 

6. USE WORKING SOFTWARE AS DETAILED DESIGN DOCUMENTATION 

7. DEVELOP A TECHNIQUE FOR MAKING DECISIONS TO BORROW TOOLS, APPROACHES, OR 
SOFTWARE VS. BUILDING TOOLS, APPROACHES, OR SOFTWARE 

8. ENFORCE AN END-TO-END IMPLEMENTATION STRATEGY - IMPLEMENT IN LAYERS NOT 
SEGMENTS 

9. FORMALLY ESTABLISH OPERATIONAL EFFECTIVENESS AS A TEST CRITERION 

10. DEVISE TEST PLANS WHICH CERTIFY OPERATIONAL EFFECTIVENESS IN REAL OR 
SIMULATED OPERATIONAL ENVIRONMENTS 
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FOCUSING THE TECHNICAL PERSPECTIVE 

ADAPTATIONS FOR EASY ACCOMMODATION OF CHANGE 



2. INCLUDE CODE STRUCTURE ASSESSMENTS AS A FORMAL PART OF 
DESIGN REVIEWS - FIND MODULES WITH SIMILAR FUNCTIONALITY AND 
GENERALIZE TO ELIMINATE "DUPLICATES" 



4. PERMIT MACHINE DEPENDENCY ONLY WHEN STRONGLY JUSTIFIED 

5. DEVELOP AN EVOLUTIONARY ACQUISITION STRATEGY DESIGNED FOR 
MULTIPLE CYCLES OF DESIGN AND IMPLEMENTATION 

- 17 - 
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SUMMARY 


• TRADITIONAL PRACTICE OF SYSTEMS ENGINEERING MANAGEMENT 
ASSUMES REQUIREMENTS CAN BE PRECISELY DETERMINED AND 
UNAMBIGUOUSLY DEFINED PRIOR TO SYSTEM DESIGN AND 
IMPLEMENTATION; PRACTICE FURTHER ASSUMES REQUIREMENTS 
ARE HELD STATIC DURING IMPLEMENTATION 

• HUMAN-COMPUTER / DECISION SUPPORT SYSTEMS FOR SERVICE 
PLANNING AND SCHEDULING APPLICATIONS DO NOT CONFORM WELL 
TO THESE ASSUMPTIONS 

ADAPTATIONS TO THE TRADITIONAL PRACTICE OF SYSTEMS 
ENGINEERING MANAGEMENT ARE REQUIRED 

FOR OPERATIONAL EFFECTIVENESS: DOING THE RIGHT JOB EFFICIENTLY 
FOR EXTENSIBILITY: EASY ACCOMMODATION OF CHANGE 

. BASIC TECHNOLOGY EXISTS TO SUPPORT THESE ADAPTATIONS 

• ADDITIONAL INNOVATIONS MUST BE ENCOURAGED AND NURTURED 

• CONTINUED PARTNERSHIP BETWEEN THE PROGRAMMATIC AND 
TECHNICAL PERSPECTIVE ASSURES PROPER BALANCE OF THE 
IMPOSSIBLE WITH THE POSSIBLE 
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PRESENTATION OUTLINE 


PART I: A PROGRAMMATIC PERSPECTIVE 

• STATING THE MANAGEMENT CHALLENGE 

• DISSECTING THE MANAGEMENT CHALLENGE 

• RESPONDING TO THE MANAGEMENT CHALLENGE 

• FOCUSING THE TECHNICAL PERSPECTIVE 

• SUMMARY 


PART II: A 


TECHNICAL PERSPECTIVE 

REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 

GOOD AND BAD STARTING POINTS FOR THE DESIGN 

PROJECTING THE CONSEQUENCES OF OPERATIONS 
CONCEPTS 

SUMMARY 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 

CHARACTERISTIC: THE MERIT OF A PLAN IS DIFFICULT TO QUANTIFY- 

PLANS USUALLY REPRESENT "ACCEPTABLE 
COMPROMISES" 


QUANTIFIABLE: 


^ (START TIME, RESOURCE UTILIZATION, SATISFIED REQUESTS) 


NON-QUANTIFIABLE: 

• JOE LIKES IT AND HE USED TO DO THE PLANNING 

• EVERYBODY CAN LIVE WITH IT 

• IT'S OK IF NEXT WEEK THE OTHER USERS CAN HAVE 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE MERIT OF A PLAN IS DYNAMIC 



• CIRCUMSTANCES CHANGE 

• MERIT MIGHT BE FUNCTION OF HOW THE PLANS LOOK 
OVER SEVERAL PLANNING HORIZONS 


REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE MERIT OF PLAN IS DEPENDENT ON THE PROCESS 

USED TO GENERATE IT. 





NO INFORMATION 
ABOUT PROCESS 


PROCESS INFORMATION 
PROVIDED 


MERIT OF THE 
PLAN ‘ CHANGES' 


• SAME PLAN LOOKS GOOD OR BAD DEPENDING ON NUMBER 
OF ALTERNATIVES EXAMINED 

• MERIT OF PLAN CANNOT BE DETERMINED FROM THE 
INFORMATION IN THAT PLAN 

• MERIT IS PROCESS NOT PRODUCT DEPENDENT 

• THIS CHARACTERISTIC IS FUNDAMENTALLY AND CRITICALLY 
DIFFERENT FROM ENGINEERING SYSTEMS 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE INFORMATION FLOW CONTENT BETWEEN 

SERVICE REQUESTER AND THE PLANNER ARE VERY 
DIFFICULT TO PREDICT 


xuIm m E L HE T o TAL INFORMAT 'ON (IN BITS) NEEDED TO RESOLVE THE RESOURCE ALLOCATION; 
I HEN N X B._ = C. 



BITS PER MESSAGE B tJt 
M 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 

CHARACTERISTIC: THE TIME REQUIRED TO BUILD A PLAN IS LONGER 

THAN ORIGINALLY PREDICTED 

A 

DEGRADATION DUE TO INCREASE IN OPERATIONAL COMPLEXITY 
ACHIEVED PLANNING AND REPLANNING TIME 

DESIGNED PLANNING AND REPLANNING TIME 

HP 


— REGION OF INOPERABILITY - 


LOSS DUE 
TO DESIGN 
FLAWS 




DESIGNED PLANNING HORIZON 

• Tp IS THE TOTAL PLANNING AND REPLANNING TIME IN HORIZON K FOR 
ACTIVITIES TO OCCUR IN HORIZON K + 1 

• Hp IS THE LENGTH OF THE PLANNING HORIZON 

• CLEARLY Tp/Hp < 1 TO MAINTAIN OPERATIONS 

• WHAT SHOULD BE THE DESIGN VALUE OF Tp/Hp? 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE SEQUENCE OF PLANNING TASKS CANNOT BE 

DETERMINED AT DESIGN TIME 



TASK SEQUENCE DETERMINABLE TASK SEQUENCE DETERMINABLE 

AT DESIGN TIME AT TASK PERFORMANCE TIME 


GOOD AND BAD STARTING POINTS FOR THE DESIGN 

• DESIGN THE SYSTEM AS A REPLANNING SYSTEM 


- REPLANNING IS A MORE FREQUENT TASK IN MOST OPERATIONAL 
ENVIRONMENTS 

- PLANNING CAN BE ACCOMMODATED AS A SPECIAL CASE OF 
REPLANNING 


- FIRST COME / FIRST SERVED ALLOCATION (i.e., DEMAND 

ASSIGNMENT) CAN BE ACCOMMODATED AS A SPECIAL CASE OF 
PLANNING 
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GOOD AND BAD STARTING POINTS FOR THE DESIGN 


• DESIGN THE SYSTEM INITIALLY TO ALLOW HUMANS TO MAKE ALL 
DECISIONS 


- ALGORITHMS SHOULD BE DESIGNED TO EMULATE HUMAN 
DECISION BEHAVIOR 


ONLY DECISION MAKING THAT IS DETERMINED TO BE ROUTINE 
SHOULD BE DELEGATED TO THE MACHINE 


- OPERATIONAL EXPERIENCE IS NEEDED TO DETERMINE WHICH 
DECISIONS ARE ROUTINE 
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GOOD AND BAD STARTING POINTS FOR THE DESIGN 


• DESIGN THE SYSTEM ORIGINALLY TO HANDLE POOLED RESOURCES 

- POOLED RESOURCES CAN ACCOMMODATE ANY QUANTITY OF A 
SHARED RESOURCE 


- INDIVIDUAL RESOURCES CAN BE ACCOMMODATED AS A SPECIAL 
CASE OF POOLED RESOURCES 
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GOOD AND BAD STARTING POINTS FOR THE DESIGN 


• DESIGN THE SYSTEM ORIGINALLY TO HANDLE GENERAL TEMPORAL 
RELATIONSHIPS 

- ACCOMMODATE NUMEROUS SEQUENCE RELATIONSHIPS AS 
SPECIAL CASES 

— PREDECESSOR / SUCCESSOR RELATIONSHIPS 

— MINIMUM SEPARATION 

— MAXIMUM SEPARATION 

— MINIMUM OVERLAP 

— MAXIMUM OVERLAP 

-- SPECIFIED OVERLAP 

- - ONE ACTIVITY ANY TIME DURING ANOTHER 


PROJECTING THE CONSEQUENCES OF 
OPERATIONS CONCEPTS 


• UNDERSTANDING OUR PROBLEM DOMAIN IS VERY IMPORTANT 

- EXAMPLE: SNC IS NQI PRIMARILY 

— A S/C CONTROL CENTER 
— A COMMUNICATIONS SYSTEM 
— A COMMAND AND CONTROL FACILITY 

sue IS 

— A DECISION SUPPORT SYSTEM 
-- A SERVICE PLANNING CENTER 
— A SERVICE PROVIDER/FACILITATOR FOR USERS 

- THE RIGHT TECHNIQUES FOR THE WRONG DOMAIN WONT HELP 


• THE DESIGN CONSEQUENCES OF AN OPERATIONS CONCEPT CAN BE 
PREDICTED 

- SEEMINGLY APPROPRIATE CONCEPTS CAN LEAD TO 
UNACCEPTABLE COSTS, COMPLEXITIES, etc. 

- A METHODOLOGY FOR PREDICTING THE DESIGN CONSEQUENCES 
OF AN OPERATIONS CONCEPT HAS BEEN DEVELOPED 
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PREDICTING DESIGNS FROM OPERATIONS CONCEPTS: 

AN EXAMPLE 


OPS CONCEPTS "DIMENSIONS” 

• HUMAN/COMPUTER DECISION 
ROLES 

• NUMBER OF USER-TO-SERVICES 
INTERFACES 

• USER-TO-CENTER COMMUNICATION 
STYLES 

• REPLANNING PHILOSOPHY 

• REQUEST SATISFACTION GOALS 

• USER KNOWLEDGE OF TDRS 

• USER KNOWLEDGE OF NETWORK 

• SERVICE CONFIRMATION RESPONSE 

• RELIABILITY OF SERVICES 

• SECURITY OF USERS 

• PERCEIVED ABUNDANCE OF 
RESOURCES 

• PERCEIVED COMPLEXITY OF 
DECISIONS 

• DEVELOPMENT vs OPERATIONAL 
COST TRADEOFFS 



• USE DIGITAL 
MSG'S FOR COMM 

• FAULT ISOLATION 
IN NCC 

• SCHEDULE BY 
PRIORITY 

• FEED SERVICE 
ACCTG BACK TO 
SCHEDULER 
PERIODICALLY 
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SUMMARY 


PAST PROBLEMS HAVE THE FOLLOWING ORIGINS: 

• NOT RECOGNIZING THE UNUSUAL AND PERVERSE NATURE OF THE 
REQUIREMENTS (FOR PLANNING AND SCHEDULING) 

• NOT RECOGNIZING THE BEST STARTING POINT ASSUMPTIONS 
(GENERAL CASES) FOR THE DESIGN 

• NOT UNDERSTANDING THE TYPE OF SYSTEM THAT WE'RE BUILDING 

• NOT UNDERSTANDING THE DESIGN CONSEQUENCES OF THE 
OPERATIONS CONCEPT SELECTED 


THE GOOD NEWS IS THAT WE: 

• NOW HAVE MORE SUCCESSFUL SYSTEMS TO EXAMINE 

• NOW HAVE A GOOD COLLECTION OF CLASS-LEVEL REQUIREMENTS 

• NOW RECOGNIZE THE GENERAL CASES THAT ACCOMMODATE THE 
REQUIREMENTS FROM A PARTICULAR DOMAIN AS PARAMETRIC 
SPECIAL CASES 

• ^LT^pjJ^ T ®ygs N T ° PREDICT THE CONSEQUENCES OF OPS CONCEPT 
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Proposed Planning & Scheduling 
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in the CDOS Era 
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Todd Welden CSC/520 
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GSFC / CSC 


DSTD 
Code 520 


Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


Agenda 


• Introduction 

• Proposed SNC data flow for CDOS era customers 

• Generic Scheduling Concept 

• P&S services SNC could provide in the CDOS era 

- Provide security 

- Maintain a data base 

- Generate universal time interval sets 

- Process queries 

- Process a robust generic request language 


December 1990 


GSFC / CSC 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


Introduction 


Motivation for this presentation 

• Studies indicate that the current NCC mode of operation needs to 
be enhanced to meet the needs of the mid to late 1990s. 

- CDOS Operations Management Service (COMS) Planning and 
Scheduling Concept Assessment 
(DSTL-90-010, CSC/TM-90/6079) 


• There is a need to simplify the request interface for SN services 

- More complex missions 

- More flexible spacecraft operations 

- More scheduling data volume 

- Events per spacecraft and scheduling period 


EOS Planning/Scheduling/Command Management Study 
(CSC/TM-90/6054) 


L- December 1990 


GSFC / CSC 


3-J 


F-3 


DSTD 

Code 520 Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


Proposed SNC data flow for CDOS era customers 



L. December 1990 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


Motivation for Generic Scheduling Usej 


Proposed for all missions in the CDOS era, in some form 

- COBE is using a customized "generic" request interface for user 
requests 

- ERBS is using a customized "generic" request interface for user 
requests 

- UARS will be using generic scheduling 

- EOS plans to use generic scheduling 


L- December 1990 


GSFC / CSC 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


Generic Scheduling Concept 



Encompasses four major classifications of requests 


Request 

Flexibility 


• Requests for 
multiple 
activities with 
no flexibility 


Number 

Of 

Activities 

Per 

Request 

• Requests for a 
single activity 
with no 
flexibility 



* Requests for 
multiple 
activities that 
are flexible 


• Requests for a 
single activity 
that are flexible 


L December 1990 


GSFC / CSC 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


Generic Scheduling | 



Generic scheduling is a viable mode of operation for the SNC 
— Supports specific / inflexible requests 

- Allows a great deal of customer flexibility 

- Allows customers to symbolically define and reference constraints 

- Allows the expression of complex relationships 

- Allows single requests for multiple instances of the same activities 
— Allows flexible resource requirements 

- Allows requests with flexible durations 

- Allows the scheduler more flexibility when scheduling 

- Leads to less impact when rescheduling or adding new events 

December 1990 csc 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


P&S services SNC could provide in the CDOS era 

Provide Security 


] 


Motivation: 

— Access to mission data must be restricted to only the owner 
Service: 

— Access to mission data only by owner 

— Current NCC restrictions are adequate 


December 1990 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


P&S services SNC could provide in the CDOS era 

Maintain a Data Base 


Motivation: 

- SNC is always on-line 

- Missions require the same type of data maintained by SNC 

- Provides a centralized repository for data 

- Ensures data compatibility between customers and SNC 

- Reduces redundancy of data flows 

Service: 


• Maintain a data base of 

- Configuration codes 

- UAV data 

- PSAT data 

- Ephemeris data 

- Previously submitted requests 

- Time interval sets 


L- December 1 990 


GSFC / CSC 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


P&S services SNC could provide in the CDOS era 

Generate Universal Time Interval Sets 

| 


Motivation: 

- All customers will need the universal time interval sets 

- Standardizes format and contents 

- Leads to a standardized mode of operation with SNC 
Service: 

• Generate time interval sets from UAV, PSAT, Ephemeris data 
for: 

- TDRS contacts 

- Orbit starts/stops 

- Spacecraft days/nights 


L- December 1990 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


P&S services SNC could provide in the CDOS era 

Process Queries 


Motivation: 

- Reduces customer and SNC asynchronous data traffic 

- Provides customers with correct and current information 

Service: 

• Send to the customer 

- TDRSS schedules 

- Configuration codes 

- UAV data 

- PSAT data 

- Ephemeris data 

- Previously submitted requests 

- Time interval sets 


December 1990 


GSFC / CSC 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 


P&S services SNC could provide in the CDOS era | 

Process a Robust Generic Scheduling Language | 

Motivation: 

- Allows all missions to use the same flexible, robust language 

- Standardizes the scheduling language and SNC interface 

- Most CDOS era missions will have their own scheduler for 
mission activities 

- Leads to standardization of the scheduling engine core 

- Leads to a standard scheduling language for 

- Mission scheduling 

- Investigator to mission interface 

- Allows customers to specify multiple options for support 

- Allows the scheduler flexibility in the scheduling of the requests 

- Allows the scheduler to produce a schedule that retains as much 
of the flexibility as possible based on the final resource usage 

- Allows schedule modification with minimal perturbation 

- Rescheduling causes less impact and can be mostly automated 

December 1990 GSFC / CSC 
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Proposed Planning & Scheduling Services for the SNC in the CDOS Era 
i = 

P&S services SNC could provide in the CDOS era 

Process a Robust Generic Scheduling Language 


Service: 

- Allow additions, deletions, and replacements of: 

- Generic and specific requests 

- Individual request instances (events) 

- Pending (i.e. not yet scheduled) events 

- Scheduled events 

- Customer-defined time interval sets 

- Allow one generic request to generate multiple events 

- Allow flexible time intervals (time tolerance / windows) 

- Allow flexible request durations 

- Allow preferred and alternate sets of resource requirements 

- Allow a "wildcard" TDRS ID and antenna ID 


December 1 990 


GSFC / CSC 
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An RF Interference Mitigation Methodology 
with Potential Applications in Scheduling 



• Communications Link Analysis and Simulation 
System (CLASS) 

• Space Network RF Mutual Interference and 
Scheduling 

• RF Interference Mitigation Methodology 

• Interference Mitigation Aid for Scheduling 

• Numerical Examples 

• Conclusions and Future Work 
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An RF Interference Mitigation Methodology 
with Potential Applications in Scheduling 
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10.1 


Communications Link Analysis & 
Simulation System (CLASS) 


G 
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DIRECTORATE 


CODE 500 


• Unique software tool for the prediction and evaluation of 
TDRSS/user spacecraft communications link performance. 

• End-to-end modeling of Space and Ground Networks, 
channel environment, and user spacecraft communications 
systems. 

• All communications channel parameters that affect link 
performance, including interference, are maintained in 
CLASS data bases. 

• Developed by NASA Goddard Space Flight Center 
(GSFC) Code 531. 
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directorate CLASS Int6rf6r©nce Analysis and 

CODE 500 Mitigation Tools 



• Interference analysis and mitigation tools have been 
developed in the CLASS environment for use in: 

-- communications performance evaluation 

- mission planning 

• Potential applications in: 

-- analysis, evaluation, and optimization of user 
schedules 
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with Potential Applications in Scheduling Q X 


Space Network RF Mutual 


Interference and Scheduling 
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DIRECTORATE Space Network RF Mutual 
CODE 500 1 Interference and Scheduling 



• Increasingly competitive climate for 
scheduling of Space Network resources in the 
Space Station era. 

• Potential RF mutual interference warrants 
increasing concern in terms of efficiency in 
network resource allocation and scheduling. 

• Scheduling efficiency of current network 
operations system could be enhanced through 
consideration of communications performance 
in mutual interference mitigation. 

• CLASS interference analysis tools can be 
used in efforts to enhance network scheduling 
efficiency. 
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An RF Interference Mitigation Methodology 
with Potential Applications in Scheduling 


Interference Mitigation Methodology 
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. STEP 1 


For every given pair of desired and interfering signals, 
determine the discrimination required to guarantee 
nonnegative BER link margin. 
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• Required discrimination 



"Required S/I" is the value of S/I such that the degradation of the desired user's signal 
equals its worst case channel margin. The worst case channel margin is a parameter 
that characterizes the desired user's link performance. 

"Worst S/T is determined by formulating S/I as a function of the separation angle 
between interferer and desired user. "Worst S/l" designates the global minimum of 
this function. 
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G ^ C 

Interference Mitigation Methodology 


• The signal to interference level ratio S/I in dB at TDRS is defined 
as a function of the separation angle a between the desired user 
and the interferer as seen from TDRS: 


f(a) = (P d + G(0)) - (P, + G(a) + Ra)) + G P + A P + L js 
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Interference Mitigation Methodology 



Pd = the worst case (maximum range) TDRS received 
power at unity antenna gain for the desired user (dB) 
including the loss due to the nonperfect polarization match 
between the TDRS and desired user antennas. It is 
assumed that the desired user is on the TDRS antenna 
boresight and that the desired user antenna is pointing 
toward TDRS. Pd includes contributions from stochastic 
sources such as multipath (vehicle, earth, and atmospheric) 
and RFI. 

Pi = the best case (minimum range) TDRS received power 
at unity antenna gain for the interferer (dB). 

G = the TDRS antenna gain (dB) as a function of the angle 
alpha. 

R = the polarization rejection of the interferer signal at the 
oppositely polarized TDRS antenna (dB) as a function of the 
angle alpha. The value of R is always negative when 
rejection is present. 
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Interference Mitigation Methodology 



Gp = 10 * ALOG10 (Desired user PN chip rate/Desired 
channel symbol rate) is the processing gain (in dB) of 
the PN spread signal 

Ap = 10 * ALOG10 (Interferer channel PN chip 
rate/Desired channel symbol rate) is the reduction 
factor (in dB) if the interferer is PN spread when the 
desired channel is not PN spread. 

Lfs = reduction of interferer power due to frequency 
separation. 
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Interference Mitigation Methodology 



• Step 2 

For every given pair of desired and interfering signals, 
calculate the required separation angle (the largest 
separation angle between the desired user and interferer 
that provides the required discrimination as determined in 
Step 1). 

This calculation utilizes the TDRS antenna gain pattern, 
adjusted as necessary to reflect polarization rejection of 
the interferer signal. 
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Adjusted Antenna Gain Pattern 
(Example) 


S F C 


<i2X'*** 




0. s 


i 5 


Loss (dB) 


-2 

-S 

-6 

-8 

-10 

-12 

-IS 


Polarization Rejection (R) 


/ 


L J 


2 


Polarization rejection modeled as a lunction 
of angle off boresight at the TDRS SA antenna 
when the transmitting antenna Is that of the 
Space Station Manned Base. 


required discrimination 5 = - A(G + R) 
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An RF Interference Mitigation Methodology 
with Potential Applications in Scheduling 


Interference Mitigation Aid for 
Scheduling 
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Numerical Example 


s F c 


• These missions operate at Ku band with carrier 
frequency equal to 15.0034 GHz, unspread. 


~ Space Station Manned Base (SSMB) versus 
Space Shuttle Orbiter (SSO) 


- Earth Observing System (EOS) versus Space 
Shuttle Orbiter (SSO) 


G-21 


SSO operates with Right Circular Polarization (RCP). Link 
characteristics are as follows: 


CHANNEL 

DATA RATE 
(kbps) 

EIRP 

(dBW) 

LINK MARGIN 
(dB) 

Channel 1: Subcarrier Q 

192 

39.4 

19.0 

Channel 2: Subcarrier 1 

2,000 

43.6 

13.5 

Channel 3: Baseband 

50,000 

51.0 

1.5 


Channels 1 and 2 are rate 1/2 convolutional coded. 
Channel 3 is uncoded. 
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Numerical Example (continued) 
- SSO Link Characteristics 
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DIRECTORATE Numerical Example (continued) 
CODE 500 -- SSMB Link Characteristics 



SSMB operates with Left Circular Polarization (LCP) at data 
rates of 300 Mbps and 50 Mbps. 


CHANNEL 

DATA RATE 
(Mbps) 

EIRP 

(dBW) 

LINK MARGIN 
<dB) 

1 

150 

57.1 

3.0 

Q 

150 

57.1 

3.0 

1 

25 

57.1 

10.8 

Q 

25 

57.1 

10.8 


The parameters given above for SSMB are preliminary and 
subject to change. 
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Numerical Example (continued) 
-- EOS Link Characteristics 



EOS operates with RCP at a data rate of 300 Mbps. 


CHANNEL 

DATA RATE 

EIRP 

LINK MARGIN 


(Mbps) 

(dBW) 

(dB) 

1 

150 

57.6 

3.6 

Q 

150 

57.6 

3.6 
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Numerical Example (continued) 
-Interference Analysis Results 



There is no unacceptable interference between the EOS 300 
Mbps link and the SSO channels 1 and 2. 


There is no unacceptable interference between the SSMB 300 
Mbps link and the SSO channels 1, 2, and 3. 


Case 1 Case 2 


Desired User 

User ID 

SSO 

SSO 


Channel 

3 

3 


Polarization 

RHC 

RHC 


Worst Case Margin (dB) 

1.5 

1.5 

Interferer 

User ID 

EOS 

SSMB 


Polarization 

RHC 

LHC 


Axial Ratio (dB) 

1.5 

2.1 

S/I 

Required (dB) 

6.2 

9.0** 


Boresight (dB) 

-11.6 

4.0 


Worst Case (dB) 

-11.6 

4.0 

Required Discrimination (dB) 

17.8 

5.0 

Required Separation Angle (deg) 

0.74 

0.92 


Note: CLASS simulation result. 
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-Potential interference Intervals 



<0 3 
w 


4J 
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Mitt Mill 


Ground Elapsed Time Offset (Seconds) 


Assumes the users (SSO and SSMB) have identical orbits 
except for a 20 degree difference in orbital phasing. 

During the 24 hour period, potential interference exists for 
a total of approximately 20 minutes for each TDRS. 
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An RF Interference Mitigation Methodology 
with Potential Applications in Scheduling 


Conclusions and Future Work 
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Conclusions and Future Work 



• Tools for interference analysis and mitigation have been 
developed in the CLASS environment for: 

~ communications performance evaluation 
- mission planning 


Potential applications are seen in: 

— analysis, evaluation, and optimization of user 
schedules 


• Tools producing "required separation angles" and 
"potential interference intervals” can be used as an aid to 
mutual interference mitigation within a scheduling system. 


Possible future consideration of multiple interferers. 
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AUTOMATED CONFLICT RESOLUTION 

ISSUES 


Systems Development Division Jeffrey S. Wlke 

Systems Integration Group ( 213 ) B1 3-4266 

One Space Park 
Redondo Beach, CA 90278 


H-l 


INTRODUCTION 



Systems Integration Group 
Systems Development Division 


Purpose: 

• To initiate discussion of how conflicts for Space Network 
resources should be resolved in the ATDRSS era. 

Topics: 

• Describe how resource conflicts are currently resolved. 

• Describe issues associated with automated conflict 
resolution. 

• Present conflict resolution strategies. 

• Suggest discussion topics. 


2 
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CURRENT SN CONFLICT RESOLUTION 


Systems Integration Group 
Systems Development Division 
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CURRENT OPERATIONAL LIMITATIONS 



Systems Integration Group 
Systems Development Division 


Current conflict negotiation is a verbal, time consuming 
process between Forecast Analysts and user POCCs. 

Security prohibits POCCs from accessing entire schedule. 

Forecast Analyst lacks automated scheduling tools and user 
knowledge. 

Current SN service requests do not utilize POCC tolerance. 

- Requests allow specifying plus or minus time tolerance. 

- Configuration codes may indicate "open selection" for antenna 
and interface channel. 
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CURRENT SOFTWARE LIMITATIONS 


TRW 

Systems Integration Group 
Systems Development Division 


Current NCC scheduler emphasizes conflict avoidance, 
rather than conflict resolution. 

- Events scheduled to avoid potential conflicts. 

- Leave largest gap of unscheduled time 

- Look-ahead metric schedules event to avoid conflict with remaining events. 

No knowledge of the applicability or preference of individual 
conflict resolution strategies. 
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CURRENT CONFLICT RESOLUTION 


Systems Integration Group 
Systems Development Division 


3 . 96 % 2 29% 



■ NO CONFLICTS 

■ RESOLVED BY ALT. UNK 

■ RESOLVED USING TIME SLIP 

E RESOLVED USING COMBINATION 
□ RESOLVED BY DELETION 


The fact that ninety percent of the conflicts were resolved indicates 
that user flexibility exists. 
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ATDRSS ERA CONFLICT RESOLUTION 


Systems Integration Group 
Systems Development Division 


ATDRSS era service requests will increase three to ten fold. 

Manual conflict resolution will cause unacceptable response 
times and life cycle costs. 

Automated conflict resolution requires knowledge: 

- Embedded in the SNC scheduling system. 

- Identified by the user POCC in each specific service request 
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EMBEDDED KNOWLEDGE 



Systems Integration Group 
Systems Development Division 


Knowledge requirements: 

• User capabilities 

• User preferences 

• SN resource data 

Conflict resolution profile created for each user POCC 

• Hierarchy of conflict resolution strategies 

• Service parameter tolerances and dependencies 
SNC generated alternatives approved by the user POCC. 
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USER SPECIFIED KNOWLEDGE 


nrss 

Systems Integration Group 
Systems Development Division 


Include knowledge in the user POCC service request. 

Prioritize request tolerances and alternatives. 

Information exchange facilitated by implementation of a user 
Pocc workstation. 

- Graphically display schedule and service flexibility. 

- Simultaneously display data at the SNC and POCC. 
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FACTORS INFLUENCING CONFLICT 
RESOLUTION 



Systems Integration Group 
Systems Development Division 


Organizational goals affecting conflict resolution are: 

• NASA established user POCC priority. 

• Certain users assigned specific links. 

• Hold back resources as spares. 

• Maximize utilization of single resources. 

• Leveling of resource utilization across the system. 

• Rewarding cooperation. 

Operational limitations affecting conflict resolution: 

• Development (forecast) period. 

• Maintenance (active) period. 

• Spacecraft emergencies. 

Ill 
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MANUAL CONFLICT RESOLUTION 


Systems Integration Group 
Systems Development Division 


Special circumstances will require manual conflict resolution 
by the SN scheduling analyst. 

- Two POCCs with same priority (Space Station and Space 
Shuttle) have a resource conflict. 

- Spacecraft emergencies conflict with higher priority user POCC 
services 


1 1 
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CONFLICT RESOLUTION STRATFnTFS 

Potential strategies include: 

• Priority. 

• Moving a service in time. 



Systems Integration Group 
Systems Development Division 


• Moving a service to the previous or next valid view 
period. 


• Switching to an alternate resource. 

• Shrinking a service duration. 

• Breaking up a prototype event into individual services, 
and performing separate conflict resolution strategies on 
the individual services. 


• Breaking up a service into multiple discontinuous 
services, or gapping. 

• Combinations of the above strategies. 

• Deleting a service from the schedule. 
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mvf 

Systems Integration Group 
Systems Development Division 

DISCUSSION TOPICS 

• What specific conflict resolution strategies are applicable to the 
user POCCs? 

• How much would conflict resolution strategies and preferences 
vary between services of a specific user POCC? 

• How much would conflict resolution strategies and preferences 
vary between different user POCCs? 

• Does a hierarchy of strategy preferences exist? 

• Under what circumstances should manual conflict resolution be 
required? 

• How amenable to automatic conflict resolution are user POCCs? 

• How much and what type of tolerance could be communicated to 
the NCC from user POCCs? 

• How much would tolerances vary between services of a specific 
user POCC? 
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Effect of Locus of Resource Control 
on Operational Efficiency in 
Distributed Operations 

A. L. Geoffroy 

Martin Marietta Information & Communication Systems 
( 303 ) 977-8186 


Spaed Network Control Workshop, 
Goddard Space Flight Center 
Dec. 12&13, 1990 



OVERVIEW 


PROBLEM 


SNC FROM THE CUSTOMER'S PERSPECTIVE 

REQUIREMENTS FOR COORDINATING COMM AND OTHER RESOURCES 


LOCUS OF CONTROL IN DISTRIBUTED OPERATIONS 


• DIFFERENT WAYS TO DISTRIBUTE CONTROL 


EFFICIENCY 


GENERAL CONSIDERATIONS 

EFFICIENCY EFFECTS DEPENDING ON CONTROL DISTRIBUTION 


RECOMMENDATIONS 


Space Network Control Workshop. 
Goddard Space Fight Oerter 
Dec. 12A13, 1990 


/via ft t//s/ /wxa /?/£• rrv» 


Loan at Resource Control and 
Operational Ettoency in Dstribuled 
Operations 1 

A. L. Geoffroy 


PRECEDING PAGE BLANK NOT FILMED 





ACRONYM & ICON LIST 


ATDRS Advanced Tracking and Data Relay 
Satellite 

CDOS Customer Data and Operations 
System 

DOC Discipline Operations Center 

EMOC Eos Mission Operations Center 

Eos Earth Observing System 

HST Hubble Space Telescope 

ICC Instrument Control Center 

MSOCC Mission Support Operations Control 
Center 

NASCOM NASA Communications 


STOCC 


STSMCC 


Hf 35 


ATDRS 


v\ M \V 


Payload Operations Integration 
Center 

Payload Operations Control 
Center 

Space Network Control 

Space Station Freedom 

Space Station Control Center 

Space Telescope Operations 
Control Center 

Space Transportation System 
(Shuttle) 

Space Transportation System 
Mission Control Center 

White Sands Cpmplex 


Generic 

Satellite 


Space Network Control Workshop. 
Goddard Space Fbght Center 
Dec. 1ZA13. 1990 


Locus at Resource Cor* no! and 
Operational Efficiency in Dtstrtouted 
Operations 2 1 

A. L. Geoffrey Ref Only 
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DEMANDS ON THE SNC 


LARGE NUMBER OF USERS 

DIVERSE USER REQUIREMENTS 

DIFFERENCES IN TIMING OF INPUT REQUIREMENTS 

CONTINGENCY HANDLING 

SYSTEM RESPONSIVENESS 


Space Network Control Workshop. 

HI /vr>i /7 /f rr>a | 

Locus of Resource Control and 


Goddard Space Flight Center 
Dec 12&13. 1990 


Operational Efficiency in DtstntxjlecJ 
Operations 
A l Geoffroy 

3 
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SHARING INFORMATION and SHARING CONTROL 


ACCESS IN ANY DISTRIBUTED NETWORK MUST BE DISTRIBUTED 
BUT CONTROL MAY OR MAY NOT BE 


WHEN MANY NODES HAVE A LARGE NUMBER OF INTERACTIONS. 
CENTRALIZED CONTROL EASES THE SCHEDULING PROBLEM 


IN NETWORKS WHERE INTER-NODE INTERACTIONS ARE WELL 
PARTITIONED INTO SMALLER LOCAL NETWORKS, DISTRIBUTED 
CONTROL IS PREFERABLE 


DISTRIBUTION OF CONTROL MAY BE REQUIRED EVEN WHEN THERE IS 
A HIGH LEVEL OF INTER-NODE INTERACTION. BECAUSE OF : 

• SECURITY/PRIVACY 

• DISTRIBUTION OF AUTHORITY 


FLEXIBILITY OR EFFICIENCY MAY BE LOST IN A NETWORK WITH 
DISTRIBUTED CONTROL 


Space Network Control Workshop. [jaaa °* Resource Control and 

Goddard Space Flight Center Operational ElSeiency in Ootrtxited 

Dec 12*13. 1990 Operations 5 

A l Geoltroy 
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EFFICIENCY PROBLEMS UNRELATED TO DISTRIBUTION OF CONTROL 


PROBLEM SIZE 

• TOO LARGE FOR ANY KNOWN METHOD OF INTELLIGENT CENTRALIZED SCHEDULING 

• TOO MANY INTERDEPENDENCIES FOR EFFICIENCY TO BE MAINTAINED 
WITH DECOMPOSITION 

LEVEL OF PLANNING PROBLEM 

• MOVING FROM STRATEGIC PLANNING TO EXECUTABLE SCHEDULES 

- CHANGES IN LEVEL OF DETAIL NECESSITATE EITHER INITIAL 
OVERBOOKING OR INEFFICIENT MARGINS 

- CONCURRENCY OF REQUIREMENTS MUST BE TRUE FOR VALID 
SCHEDULES, BUT ONLY SUMMED REQUIREMENTS ARE AVAILABLE IN 
EARLY PHASES OF PLANNING 


FLEXIBILITY 

• THE MORE FLEXIBILITY ALLOWED IN RESOURCE ENVELOPES, THE MORE 
INEFFICIENCY INTRODUCED 


Space NetworV ControJ Wortcshop, 
Goddard Space Flight Center 
Dec 12&13, 1990 


Locus of Resource Control and 
Operational Eftoency m Distributed 
Operations 7 

A L GeoHroy 



EFFICIENCY PROBLEMS RELATED TO DISTRIBUTION OF CONTROL 


BLOCK ALLOCATIONS 

• PREDICTABILITY OF REQUIREMENTS DETERMINES EFFICIENCY 
INTERLOCKING SCHEDULES 

• TRYING TO ACHIEVE EFFICIENCY IN MULTIPLE DIMENSIONS 


SPECIFIC v. GENERIC REQUESTS 

• GENERIC REQUESTS CAN BE MOST EFFICIENTLY SCHEDULED. 
BUT POSE DIFFICULTY IN DISTRIBUTED CONTROL OF TIGHTLY 
COUPLE RESOURCES 


CONTINGENCIES IN DISTRIBUTED CONTROL SCENARIOS 

• EFFECTS AT A SINGLE NODE RIPPLE THROUGHOUT NETWORK 

• SPEED, RESPONSIVENESS AND COORDINATION PROBLEMS 


Space NmmU Control Wortuftop 
Goddard Space Fkght Center 
Dec 12413. 1990 


Locus ot Resource Control and 
Operational Efficiency tfi Distributed 
Operations 
A L GeoHroy 




RECOMMENDATIONS 


STUDY, STUDY, STUDY .... 

• RESOURCE COUPLING, INDEPENDENCE 

• REAL-TIME REQUIREMENTS 

• 'COORDINATION” CAPABILITIES 

- DESIRABILITY 

- FEASIBILITY 

- COST RISK & TIMING 

DEVELOP APPROACH BASED ON STUDY OUTCOMES, INCLUDING: 

• SYSTEM ARCHITECTURE AND DESIGN 

• OPERATIONAL REQUIREMENTS/RESTRICTIONS FOR USERS EXPLICITLY GIVEN 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12&13, 1990 
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Locus of Resource Control and 


Operational Efficiency in Distributed 
Operations 
A L Geoffroy 
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Resource ALlocation Planning Helper 

(RALPH) 

David G. Werntz 
Jet Propulsion Lab 
Pasadena, California 


RALPH Background 


Developed to plan Deep Space Network tracking, maintenance, 
and ground based science 
° 12 antennas around the world 

° 30 active users of the DSN 

° Weekly plans 

° Approximately 300 "tracks" per week 

Used to generate schedules up to 2 years in advance 

Developed within Design Team approach (close interaction) 

Operational Since 1987 

Under configuration management since 1989 


RALPH Schedule Lifecycle 


10 years - 2 years 


2 years - 8 weeks 


8 weeks - real time 


Forecasts of resource utilization 
Forecasts of user contention 
Evaluation of mission sets 

Generation of detailed schedules 
Review and conflict resolution 
Adaptation to changing requirements 

Implementation of schedules 
Reaction to spacecraft emergencies 
Reaction to resource outages 


J-3 


DGW 2 


Scheduling Approach 

• Two pass scheduling 

° Probablistic look-ahead (profile of resource usage) 

° Schedule using profile as measure of expected conflict 

• Generic representation of problem 

° Actual problem described by external files (not code) 

° Three types of resources 
° Static 
° Variable 
° Depletable 

° Requirements described in terms of 
° Variable Separations 
° Variable Durations 

° Configuration dependent pre and post activity times 
° User Windows 
° Triggers (Viewperiods) 
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Technology Layering 


Applications Level 

• DSN (RALPH) 

• Space Station Assembly Sequence (FAST) 

• Space Station Operations Scheduling Simulation (TOMAS) 

• TDRSS Scheduling Prototype 

Toolkit Level 

• Scheduling 

• Resource Look-ahead Profiling 

• Interval Algebra 

• Conversion routines 

Foundation Level - Tree Manipulation Base Routines (TMBR) 

• Written in C (fielded on both extended-PC and VAX) 

• String storage management 

• Dynamic tree manipulation (prune, graft, qualify, etc.) 

DGW-4 


Details 


• Approximately 30,000 lines of C code (including TMBR) 

• 5-30 minutes to generate one week schedule (Micro VAX II) 

• Full Environment 

° Form-based requirements entry 

° Graphics (GKS) and text-based (Curses) schedule editors 
° Listings 
° Plots 

° Import and export facilities 
° Multi-user system 
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RALPH Directions 


• Migrate towards more iterative rescheduling capability 

• C++ version in the works 

• Change operational platform to network environment 

• Expand representational base 

• Continue to expand base of applications 
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JF»L 

CHARACTERISTICS OF 
AN OMP SCHEDULE DOMAIN 



Resource Allocation Problem 

• Over-Subscribed 

• Large Numbers of Complex 
Requests 

• Changes in Tasking 

• Changes in Environment 


Operations Mission Planner 


JPL 


WHAT IS A SCHEDULE? 


Request 


Antenna 


Task 


Resource 


Activity 
Set of Steps 
Frame 
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Timeline 

Chronology 

Temporal Data Base of Steps, 
Usage, & Direction 



TIMELINE t n 

^ i i i ' i 

Broadcast 508 
Broadcast 632 
Direction 53 
Chronogram C-12 


Operations Mission Planner 


SOAR/GFKM 
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ISSUES 

OMP Interface Designed as Developmental 
Interface for Automated Scheduling System 


Information Underload 
Information Overload 
Modifying Tasks 
Events 

Assessment of Schedule 

Development/Modification 
of Heuristics 


Strip Charts 

Histograms, Filtered Gantt 

Edit Window 

Command Window 

Statistics Display 

Animated Windows 
Chronologies 
Parameter Setting 
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Operations Mission Planner 
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SOAKA3FSC S 
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JPL 

USER INTERFACE DIMENSIONS 


Two major considerations in 
specifying a user interface: 

• Functional Distribution 

• Type of User 
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Operations Mission Planner 
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JPL 


Functional Distribution 

Example: Operations Mission Planner 


Automated Functions 


Human Functions 

Develop Schedule 


ID New Heuristics 

Assess Schedule 


Direct Manipulation of 
Schedule 

Modify Schedule 


Provide Guidance 
"Verify" Schedule 



Monitor Schedule 
Execution 



ID Problems During 
Scheduling 


Process 


Monitor 

Create 
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Operations Mission Planner 


SOAR/GFSC 10 
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JPL — 

Types of Users 

Different Types of Users Require Different Support from the Interface 


Human Scheduler 


Schedule End-User 

Adjust Scheduling Process 

Interpret Results of 
Scheduling Algorithms 

Modify Heuristics 

Perform Statistical Analysis 

Define New Heuristics 


Focus Scheduler 

Define Performance Limits 

Request Sequential Activities 
Lists 

Set Preferences 



Manipulate Tasks 
Manipulate Resources 
Input New Tasking 
Receive Output Schedules 


K-ll 


Operations Mission Planner 


SOARCFSC II 


-IPL — ^ 

INTERPRETING USER INTERACTION 


Need to interpret user interaction in the development of 
a schedule somewhere in the middle of the continuum 


User Modification to 
Schedule is 
ABSOLUTE 


Scheduler Can 
IGNORE 

Any User Change 
to Schedule 
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Operations Mission Planner 
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Example: 

Interpreting User Interaction Using 

DYNAMIC OVERLAYS 



SOAR/GFSC 1J 


JPL 

REACTIVE SCHEDULING 


User 

Request 


- Scheduler 

t 

Domain Model 


Schedule 


User 

Request + A 


User 

Request 


- Scheduler 

♦ 

Domain Model 


Schedule 


- Scheduler -► Schedule 

T 

Domain Model Domair 


ihedule — ► Scheduler — ► Schedule 

> < 

Domain Model + A User Request + A 

Operations Mission Planner 


ARWG 12*90-15 
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REACTIVE SCHEDULING 


CONT 


User Request - 
Domain Model - 


Scheduler 


Schedule 


^ 



-L- 

User 

Review 


Detailed 
Domain 
Analysis . 

J 


Schedule Change Request 


Old Schedule - 
User Request - 
Domain Model - 


Scheduler 


Schedule + a 
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Operations Mission Planner 
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TRANSITIONING THE INTERFACE 

OMP Is in the process of identifying how to 
transition from an automated/developmental interface 
to an integrated/operational interface 


| 

> 

& 
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OMP 

Provide user insight 
into what scheouling 
actions are being 
performed and Why 
the scheduler Is 
choosing those actions 
(DEBUGGING) 


Assist an end-user of 
the SCHEDULE In the 
process of Input/output 
for the scheduler 
(BLACK BOX OPERATIONS) 


H-C tnteorated 


Develop heuristics which 
can be interact ive with 
the user Provide feedback 
to the user on now his 
actions are affecting the 

schedule (interactive 

DEBUGGING) 


Assist a human scheduler 
In providing guidance 
to the scheduler 
(INTERACTIVE SCHEOULING) 


Operations Mission Planner 


SOAILCFSC 14 
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HUMAN FACTORS ISSUES IN THE DESIGN OF USER INTERFACES 
FOR PLANNING AND SCHEDULING 


PRESENTED AT THE SPACE NETWORK CONTROL CONFERENCE ON 
RESOURCE ALLOCATION CONCEPTS AND APPROACHES 

NASA/GODDARD SPACE FLIGHT CENTER 

DECEMBER 13, 1990 


Presented by: 
Elizabeth D. Murphy 


CTA INCORPORATED 
6116 Executive Boulevard, Suite 800 
Rockville, MD 20852 
(301) 816-1262 
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PREFACE 


THE SYSTEM MUST BE BASED UPON A SIMPLE, CONCEPTUALLY 
USEFUL MODEL OF THE SCHEDULING PROCESS, THE USER 
INTERFACE MUST BE NATURAL AND INTUITIVE, AND THE 
COMMANDS MUST PROVIDE A DIRECT MAPPING OF THE 
INTENTION INTO ACTION. 


-FOX, 1989 


. . . THE FIRST STEP FOR THE DESIGNER IS TO DETERMINE THE 
FUNCTIONALITY OF THE SYSTEM BY ASSESSING THE USER TASK 
DOMAIN. 


— SHNEIDERMAN, 1987 
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AGENDA 


INTRODUCTION 

ISSUES 

GUIDELINES 

DISPLAY CONCEPTS 

GENERAL RECOMMENDATIONS 


HI- 2 


INTRODUCTION 


PURPOSE — PROVIDE AN OVERVIEW OF HUMAN FACTORS ISSUES 
THAT IMPACT THE EFFECTIVENESS OF USER INTERFACES TO 
AUTOMATED SCHEDULING TOOLS 

SCOPE — SELECTED ISSUES ADDRESSED IN RECENT WORK FOR 
NASA-GODDARD CODE 522.1 
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INTRODUCTION (2) 


• METHOD 

SURVEY OF PLANNING AND SCHEDULING TOOLS 

IDENTIFICATION AND ANALYSIS OF HUMAN FACTORS ISSUES 

DEVELOPMENT OF DESIGN GUIDELINES BASED ON HUMAN 
FACTORS LITERATURE 

GENERATION OF DISPLAY CONCEPTS TO ILLUSTRATE 
GUIDELINES 


ISSUE: VISUAL REPRESENTATION OF THE SCHEDULE 

• OBJECTIVE: REDUCE MENTAL MANIPULATION AND 

TRANSFORMATION OF DATA 

• OPERATIONAL NEED: 

ALTERNATIVE LEVELS OF ABSTRACTION 

SUPPORT FOR VISUALIZING RELATIONSHIPS BETWEEN EVENTS 
SUPPORT FOR REORDERING EVENTS 
REDUCED DEMAND ON MEMORY 
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ISSUE: VISUAL REPRESENTATION OF THE SCHEDULE (2) 


• GUIDELINE: CONSIDER ALLOWING A SPECIFIC TEMPORAL ORDERING 
OF EVENTS TO EVOLVE OVER THE SCHEDULE'S LIFE CYCLE. 

• DISPLAY CONCEPT: PRECEDENCE SCHEDULING 

- FOCUS ON RELATIONSHIPS BETWEEN EVENTS AND POINTS IN TIME 

USE EVENT "CLONES” TO REPRESENT ALTERNATIVE 
SATISFACTION OF CONSTRAINTS ON AN EVENT 
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DISPLAY CONCEPT: PRECEDENCE SCHEDULING 
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ISSUE: EVALUATION OF SCHEDULES 


OBJECTIVE: INCREASE THE EASE AND EFFECTIVENESS OF SCHEDULE 
COMPARISON AND SELECTION 

INFORMATION REQUIREMENTS/CRITERIA: 

NUMBER OF REQUESTS SATISFIED 

LEVEL OF RESOURCE FRAGMENTATION 

AVERAGE PERCENTAGE OF SERVICE PROVIDED 

PERCENTAGE OF SERVICE PER USER 
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ISSUE: EVALUATION OF SCHEDULES (2) 

GUIDELINE: PROVIDE A CAPABILITY THAT SUPPORTS QUICK VISUAL 

COMPARISON OF SCHEDULES 

DISPLAY CONCEPT: HISTOGRAM 

CONVEYS RELATIVE EFFECTIVENESS OF ALTERNATIVES 

REDUCES MENTAL COMPARISON OF DISCRETE QUANTITIES 


DISPLAY CONCEPT: HISTOGRAM 


Requests 

Scheduled 

500 

400 

300 

200 

100 

0 



Si S2 S3 S4 S5 S6 S7 
Schedules 
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ISSUE: IDENTIFICATION OF AVAILABLE RESOURCES 


OBJECTIVE: SUPPORT OPERATOR HEURISTICS FOR MAXIMIZING USE 
OF RESOURCES (E.G., NEGOTIATION WITH USER, RESOURCE 
SUBSTITUTION) 

• OPERATIONAL NEED/INFORMATION REQUIREMENTS: 

DISCRETE RESOURCE AVAILABILITIES (AMOUNT BY TIME) 
REQUESTED RESOURCES 

FUNCTIONALITY FOR COMPARISON OF REQUESTED AND 
AVAILABLE RESOURCES 


1-12 
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ISSUE: IDENTIFICATION OF AVAILABLE RESOURCES (2) 


• GUIDELINE: PROVIDE ACCESS TO RESOURCE AVAILABILITIES; 

SUPPORT COMPARISON OF AVAILABLE AND REQUESTED RESOURCES; 
SUPPORT RESOURCE SUBSTITUTION. 

• DISPLAY CONCEPT: GRAPHICAL REPRESENTATION OF AVAILABLE 

RESOURCES 

FEATURES DIRECT-MANIPULATION APPROACH TO COMPARISON 
OF REQUESTED AND AVAILABLE RESOURCES 


L - 1 3 


HP-12 


DISPLAY CONCEPT: GRAPHICAL REPRESENTATION OF AVAILABLE 

RESOURCES 



L-14 
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ISSUE: SUPPORT FOR CONFLICT RESOLUTION 


OBJECTIVE: PROVIDE SUPPORT FOR OPERATOR’S MENTAL PROCESS 

OF CONFLICT RESOLUTION 

OPERATIONAL NEEDS/INFORMATION REQUIREMENTS 
RESOURCE AVAILABILITIES 
REQUEST CONTENTS AND FLEXIBILITIES 
CHANGES IN PRIORITIES 
USERS AND EVENTS IN CONFLICT 
EXTENT OF EXISTING CONFLICTS 
RESOURCE USAGE PER USER 
REQUEST-EDIT CAPABILITY 


HI 14 


ISSUE: SUPPORT FOR CONFLICT RESOLUTION (2) 


GUIDELINE: PROVIDE SUPPORT FOR CONFLICT RESOLUTION BASED 

ON ANALYSIS OF OPERATOR'S GOALS AND MENTAL OPERATIONS; 
INVOLVE OPERATORS FULLY IN THE DEVELOPMENT PROCESS 

DISPLAY CONCEPTS: DISPLAY OF CONFLICTING EVENTS 

OPTION 1: HIGHLIGHTING CONFLICTS 

OPTION 2: SUPPRESSING NON-CONFLICTING EVENTS 
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DISPLAY CONCEPT: DISPLAY OF CONFLICTING EVENTS 
(OPTION 1 - HIGHLIGHTING CONFLICTS) 



L - 1 7 


III l(> 


DISPLAY CONCEPT: DISPLAY OF CONFLICTING EVENTS 
(OPTION 2 - SUPPRESSING NON-CONFLICTING EVENTS) 



1-18 
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GENERAL RECOMMENDATIONS 


COWJITI TAS A^AL YSIS° P ^” R A * TASK ANALYSIS (FOCVS ON 
SUPPORT VISUALIZATION, DIRECT MANIPULATION OF DATA 
KEEP OPERATORS IN THE DEVELOPMENT LOOP 


L- 19 
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FLEXIBLE ENVELOPE REQUEST NOTATION 

( FERN ) 


December 13, 1990 

David Zoch 
David LaValiee 
Stuart Weinstein 


SEAS 

Systems, Engineering, and Analysis Support 


AtraSys 



• Background 


• FERN Language Concepts 


• FERN Syntax Examples 


SEAS 

Systems, Engineering, and Analysis Support 

MraSyt 
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• Science users send requests to the Resource Scheduling System. 


• Requests are requirements for planned instrument operations and are written 
in FERN. 

• The Resource Scheduling System, which may reside in a POCC, processes 
the requests and generates a schedule. 


• The schedule specifies the timeline of user activities and is distributed to the 
science users. 



• Science users must represent their resource requirements and constraint 
relationships in a format that can be interpreted by computers. 


• If their initial resource requests cannot be satisfied, science users need to 
propose reduced resource amounts or alternative experiments for their 
instrument operations. Thus, some of the science user requests may be 
flexible and complex rather than simple. 


• FERN uses a language format. For example. "TAPE_DUMP for 5 minutes to 
10 minutes" is more user-friendly than "TAPE_DUMP,5,10." This format 
allows users to state their requirements in a more direct and natural manner. 


seas LORAL 

Systems, Engineering, and Analysis Support fltraSyt 


M-4 
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Characteristics of FERN 


• ROBUST 

- Supports a variety of user resource requirements and constraints. 

- Supports alternative resource amounts and requests. 

- Supports repetitive requests ("generic requests") based on orbital events 
rather than specific start times. 

• READABLE 

- Keyword based, not positional. For example, avoids "ROB1 ,2-4,60,200-300." 

• FLEXIBLE 

- Time durations and relaxable constraints 

• OBJECT-ORIENTED 

- Data abstraction 

- Reusable data objects 

LORAL 

SEAS HaraSyt 

Systems, Engineering, and Analysis Support 

M-5 


• Flexible resource requirements 

• Flexible request durations 

• Flexible experiment timing / coordination requirements between activities 

• Scheduling information for repetitive activities 

• Alternative activities 

• Relative importance of each requirement 


SEAS 

Systams, Engineering, and Analysis Support 

M-6 


ftaroSyt 
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GENERIC REQUEST 

- Pattern of replication of activities 

- Alternative activities 

- Rules 

ACTIVITY 

- Sequence of steps that comprise the activity 

- Duration of steps 

- Constraints common to whole activity 

- Defined in database, then referenced by name in GENERIC REQUEST 

STEP 

- Amounts of resources 

- Constraints 

- Defined in database, then referenced by name in ACTIVITIES 


SEAS 

Systems, Engineering, end Analysis Support 


flereSyt 
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FERN Structures (cont’d) 


RESOURCES 

- Support user operations. 

- Are represented as scalars that vary over time. 

CONSTRAINTS 

- Restrict the times when a request can be scheduled. 

- Are specified with respect to timegraphs, activities, steps, or other requests. 

TIMEGRAPHS 

- Are used to specify time windows, view periods, preferable scheduling times, 
spacecraft events, calendar events, etc. 


LORAL 

SEAS ' = 

Systems, Engineering, and Analysis Support * r# u> 

M-9 


Generic Request 


Generic GENERIC_NAME is 

3 to AS MANY AS POSSIBLE activities per Sun_in_view 
With default min start time separation 5 minutes, 

With default max start time separation 10 minutes. 

With summed duration 4 hours, - sum of multiple activity durations is 4 hours 

With priority 2, 

With strategy Maximizing_Separation 

Schedule 

ACTIVITY1 and ACTIVITY2 
Or schedule 
ACTIVITY3 
Or schedule 

ACTIVITY4 With min start time separation 4 minutes 
End generic 


SEAS 

Systems, Engineering, and Analysis Support 


mraAL 

a«rotys 
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Activity ACTIVITY_NAME is 
Steps 

STEP1 for 1 to 8 minutes, 
idle STEP2 for 2 to 5 minutes, 

STEP3 for 5 minutes, 

interruptable STEP4 for AS LONG AS POSSIBLE 
STEP5 for 5 minutes 
With activity duration 30 minutes 
End activity 

Interruptable Step - resources of step can be re-allocated without 
disrupting activity. 

Idle Step - same as interruptable, but not displayed on timeline. Used 
to represent idle periods. 



Step STEP_NAME is 
Resources 

INSTRUMENT_X, 

POWER 5 watts, 

TDRSS_SA 1, 

Constraints 

Occurs entirely during ORB!T_DA YLIGHT, 
Starts at the same time as ACTIVITY_X, 

End step 


seas LORA I 

Systems, Englnaarlng, snd Analysis Support HsrsSg • 

H- 12 
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Resources 


Initial amount may vary over time in discrete steps 

Pooled resources contain equivalent or nearly equivalent items: 

- TDRSS is (TDRSS_E, TDRSS_W) 

- Crew member is (commander, pilot, mission_specialist) 

- Redundant equipment is (line_recorder_1 , line_recorder_2) 

Some resources are available at different times to different users 
(e.g., TDRS) 

Resources may be either durable or consumable 


SEAS 

Systems, Engineering, and Analysis Support 


LO HAL 

Rarely* 



Pooled Resources 


Resource TDRSS_SA is 
(Forever (TDRSS_E_SA1 , TDRSS_E_SA2, 
TDRSS_W_SA1, TDRSS_W_SA2 , )) 

End resource 


TDRSS SA Allocation 


TDRSS_E_SA1 
TDRSS_E_SA2 
TDRSS_W_SA1 
TDRSS W SA2 



Even though some TDRSS_SA is available at every point, 
no single antenna is continuously available. Thus, a 
request for 50 minutes of TDRSS SA is NOT satisfied. 


SEAS 

Systems, Engineering, and Analysis Support 


jJDRAL 

MrvSyt 
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Resource Availability for Pooled Resources 


Some resources are available at different times 
to different users 

For example, TDRSS communication resources are available 
at different times to different satellites, depending on the 
position of the satellite with respect to TDRSS. 

Step DATA_LINK is 
Resources 
TDRSS _E 
Constraints 

Occurs entirely during TDRSS_IN_VIEW 
End step 


TDRSS_E 

TDRSS_IN_VIEW 

Availability 


SEAS 

Systems, Engineering, and Analysis Support 
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fteroSys 



RESOURCE 1 15 units, 

RESOURCE2 (25 units, 23 units AT RELAXATION 4, 

19 units AT RELAXATION 8, 

15 units AT RELAXATION 12) 

STEP1 for (30 minutes, 28 to 30 minutes AT RELAXATION 5, 

25 to 30 minutes AT RELAXATION 15) 


SEAS 

Systems, Engineering, and Analysis Support 



MreSyt 
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Temporal Constraints 


Temporal Constraints specify when a request can be scheduled with 
respect to: 

Calendar Events, Orbital Events, Requests, or User Defined Events 

Allow for precise activity sequencing and coordinated activity 
dependencies. 

Sample temporal relationships between request A and object B are: 


rri m 


Occurs before B 
Occurs after B 

Ends 5 minutes after the start of B 
Occurs right after B 
Overlaps all of B 


A | | b | | A | Does not overlap B 


SEAS 

Systems, Engineering, and Analysis Support 


LORAL 

flerotyi 



Profiles 

Things that vary over time 


FOREVER 


CREATE 


CREATE PERIODIC 


INVERT 




UNION 


INTERSECT 


MODIFY 

With start earlier by 5, 
With end later by 5 

SELECT 1,3,4 


juiiiruum 


SEAS 

Systems, Engineering, and Analysis Support 


ftaraSyt 
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Time Formats 


Representation of Absolute Time: 

• 1990/120/09:00:15.12 April 30, 1990, 9:00:15.12 am 

• 1990/120-09:00:15.12 April 30, 1990, 9:00:15.12 am 

• 1990/4/30-09:00:15.12 April 30, 1990, 9:00:15.12 am 


1 


Representation of Relative Time: 


• 3/2:30 

• 2.5 

• 2.5 hours 

• :24.25 

• 24.25 minutes 


3 days, 2 hours, and 30 minutes 
2 hours, 30 minutes 
2 hours, 30 minutes 
24 minutes, 1 5 seconds 
24 minutes, 15 seconds 


SEAS 

Systems, Engineering, end Analysis Support 


fUrolys 
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Changes to FERN 


New FERN 

Old FERN 


• UIL like - keywords 

• LISP like - ( ) 


• Generic repetition by 
iteration or user- 
defined windows 

• Generic repetition by 
iteration 


• Direct support of 
alternatives 

* Alternatives by mutual 
exclusion 


• Flexible duration 

• Fixed duration only 


• Pooled resources 

• No pooled resources 


* Database of steps 

* Unnamed phases 


j3_ 

G 


^1^A2~~A1 
^S1_S2 S3 

R1 R2 R3 


RTl^"' 33 



SEAS 

LORAL 

Systems, Engineering, and Analysis Support 


Mr«tyi 
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-- Idle resource usage between steps of the same activity 
-- Flexible request durations 

- Relaxable constraints 

- Event driven planning/scheduling concepts 

- ESP and UIL time formats 

- Step oriented (generics -> activities -> steps) 

- Min and max delays between steps and activities 
-- User priorities 


SEAS 

Systems, Engineering, and Analysis Support 


fltroSyi 



Temporal Relationship between Two Steps 


Problem: The steps ERBS_TR_DUMP and ERBS_RANGING occur 
concurrently when command uplink and telemetry downlink are available 
(coherent transponder mode). This example shows how to specify 
relationships between steps by using a constraint expression. 


Step ERBS_TR_DUMP is 
R e $0 y rccs 

TDRSS I CHANNEL._FORWARD_l.INK, - 
TDRSSZCCHANNEL_RETURN_LINK , - 

TDRSS_Q_CHANNEL_RETURN_LINK - 

End step 

Step ERBS_RANGING Is 
Rbsou rce 

TWO_ WA Y_RANGING_AND_ DOPPLER 1, 

Constraint 

Occurs entirely during ERBS_TR_DUMP 
End step 


- mode 1.0 kbps 

- mode 1.6 kbps 

- mode 32 kbps 


SEAS 

Sy* tarns, Engineering, and Analysis Support 


Merely* 
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Maximum Activity Length to Limit Step Delays 


Problem: The transition between steps is flexible and does not need to 
occur at a specific time. Switching from command uplink only mode to 
command uplink and telemetry downlink mode may begin from 5 to 7.5 
minutes after the ERBS activity start time. 


Activity ERBS_NORMAL_CASE is 
Steps 

E^BSCMD_LOAD_AND_DOPPLER for 5 minutes to 7.5 minutes, 
ERBS_CMD_LOAD for 2.5 minutes to 5 minutes 
ERBS_ TR_DUMP_AND_RANGING for 13 minutes, 
ERBS_TR_DUMP for 10 minutes 
With activity duration for 33 minutes 
Constraint 

Starts during ERBS_WINDOW 
End activity 


SEAS 

Systems, Engineering, and Analysis Support 
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Problem: In some cases, all of the activities (instances) belonging to a 
generic request cannot be scheduled. Alternative requests are backup 
requests which tell the scheduling system how to resolve conflicts. In 
this example, the last alternative request applies only to those activities 
(instances) that remain unscheduled after the nominal request and first 
alternative request were processed. 


Generic ERBS_SUPPORT is 
1 activity per EVERY_TWO_ERBS_ORBITS 

Schedule - schedule nominal first 

ERBS_NORMAL_CASE 

Or schedule - move ranging step to try to resolve resource oonftict 

ERBS_RETURN and ERBS_SMALL_ WINDOW_ TRACKING 

Or Schedule - If one of the ERBS activities cannot be scheduled, place It within the next 3 orbits 

ERBS_BIG_ WINDOW_RE TURN and ERBS_BIG_WINDOW TRACKING 
End generic ~ 


seas LORA L 

Systems, Engineering, end Analysis Support Mrettfs 
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Temporal Relationship between Two Activities 


Problem: The CLAES instrument normally views for three days on and 
three days off. However, during a spacecraft yaw manuever, the 
science user wants to interrupt the normal view activity to close the 
instrument's aperature door. The normal view activity resumes after the 
spacecraft yaw manuever. 


Activity CLAES_CLOSED_DOOR_ VIEW_ACT is 
Steps 

CLAES_CLOSE_APERATURE_STEP for 1 minute, 
CLAES_DOOR_CLOSED_VIEW_STEP for as long as possible, 
CLAES_OPEN_APERATURE_STEP for 1 minute, 

Constraints 

Overlaps exactly UARS_YAW_MANUEVER 
Occurs entirely during CLAES_NORMAL_ VIEW ACT 
End activity 


SEAS 

Systems, Engineering, end Analysis Support 
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Idle Resource Usage between Steps 


Problem: The HALOE instrument alternately views the sunrise and 
sunset. In between, it is stowed. The idle step is used to maintain the 
minimum resources required for stowing between viewing. 


Activity HALOE_NORMAL_ACT is 
Steps 

HALOE_SUNRISE_ VIEW_STEP for 15 minutes, 
HALOE_SUNRISE_SLEW_ TO_STOW_STEP for 20 seconds, 
idle HALOE_STOW_STEP for as long as possible, - limited to about 25 minutes 
HALOE_SUNSET_VIEW_STEP ior 15 minutes, 
HALOE_SUNSET_SLEW_ TO_STOW_STEP for 1 5 seconds, 
idle HALOE_STOW_STEP for as long as possible - lor remainder of ortxt 
End activity 


SEAS 

Sy 9 tarns, Engineering, and Analysis Support 


LORAL 

Mrilyi 
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CHIMES-2: A Tool for Automated HCI Analysis 


Space Network Control Conference on 
Resource Allocation Concepts and Approaches 

December 13, 1990 


Presented By 
William J. Weiland 


CTA INCORPORATED 
6116 Executive Boulevard, Suite 800 
Rockville, MD 20852 
(301) 816-1332 
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OVERVIEW OF PRESENTATION 


.£OMPUTER-HUMAN INTERACTION MODELS (CHIMES) 
METHODOLOGY 

. CHIMES-2 PROTOTYPE 

. CHIMES FUTURE DEVELOPMENT 


N-2 
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PRECEDING PAGE 


BUNK not filmed 


PURPOSES OF CHIMES METHODOLOGY AND TOOLSET 


* FOR FIELDED COMPUTER-HUMAN INTERFACES 

- EVALUATE DEMANDS 

- PINPOINT TROUBLE SPOTS 


* FOR PLANNED CHI DESIGNS 


' £?. E PJ£ T ,MPACTS OF DESIGN CHANGES 
- SELECT FROM DESIGN ALTERNATIVES 


N-3 
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BASIC PREMISES: 


• SYSTEMS IMPOSE DEMANDS ON PERSONNEL RESOURCES 

‘ COGNITIVE 
‘ SENSORY 
- MOTOR 


HIERWrcHY^F^FUNCnolML^VEI^ANO^AnTRiBUTEi^ ° F A 


IMPROVING HUMAN-COM^/TER^NTERACTIOlf * BAS ' S F ° R 
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CHIMES: SAMPLE FUNCTIONAL HIERARCHY 


MISSION 


FUNCTION 


SUBFUNCTION 


TASK 


SUBTASK 
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CHIMES DEMAND MODEL: HIERARCHY OF ATTRIBUTES 


FUNCTIONAL LEVELS 


ATTRIBUTES 


SYSTEM MISSION 


FUNCTION 


Operating Personnel Demand 



Sensory/Cognitive 
Motor Demand 


Modality-Switching 

Demand 


Multiplexing 

Demand 


Adaptive 

Demand 


SUBFUNCTION Subfunction 

Demand 


TASK 


SUBTASK 


Task 

Demand 


Visual 

Perception 

Demand 


Auditory 

Perception 

Demand 


Analytic 

Assessment 

Demand 


Psychomotor 

Demand 


Verbal 

Response 

Demand 


N-6 
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CHIMES PROCESS 


♦ MODEL THE OPERATOR'S JOB 


RATE DESIGN-BASED DEMANDS ON OPERATOR RESOURCES* 
VISUAL, AUDITORY, ANALYTIC, VERBAL, AND MANUAL 


• EVALUATE OR PREDICT OVERALL 
PERFORMANCE) 


OPERATOR WORKLOAD AND 


IDENTIFY ACTUAL OR POTENTIAL TROUBLE SPOTS (HIGHS AND 
LOWS FOR WORKLOAD, LOWS FOR PERFORMANCE 

DEVELOP RECOMMENDATIONS TO IMPROVE THE QUALITY OF 
HUMAN-COMPUTER INTERACTIONS 


N-7 


CHI-6 


Design 

r~, 


OVERVIEW OF CHIMES METHODO LOGY 

Specification or Prototype 


i 

I i 


Step 1 : 
Define a 
functional 
hierarchy 


MODEL THE USER S TASKS 

Step 2: 
Determine 
demands 
on user 


v> 
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Step 3: 
Determine 
skills 
oft 


Available skills — 

• Visual 

• Auditory 
Analytic 

Verbal response 
Manual response 



EVALUATE/PREDICT 
USER PERFORMANCE 



v- 

ACCEPTABLE 

OESIGN 
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CHIMES-2 PROTOTYPE 


• PROVIDE PROOF-OF-CONCEPT FOR CHIMES-2 

CAPABILITIES 

- USER-SYSTEM INTERFACE 

- KNOWLEDGE BASES 

- DISPLAY ANALYSIS 

- MODIFICATION ADVICE 

- EXPLANATION FACILITY 

• FOCUS ON EVALUATION OF A SINGLE ALPHANUMERIC 

DISPLAY SCREEN 

- VISUAL DEMAND 

- ANALYTIC DEMAND 


N-9 
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CHIMES-2 PROTOTYPE: SYSTEM MODES 


K Mode 1 : 

Accept User Definition 


of interface Design 



Mode 2: 

Derive Ratings for Demand 
Attributes; Predict Workload 
Effects 


Mode 4: 

Develop 

Recommendations 


Mode 5: 

Respond to Queries for 
Explanation and On-Line Help 


CHIMES-2 


If - 10 
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TOP-LEVEL CHIMES-2 SCREEN 




N- 12 
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SAMPLE LOW-LEVEL DESCRIPTION SCREEN 



CHI-12 


ALTERNATE LOW-LEVEL DESCRIPTION SCREEN 



Detailed Screen Layout 
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CHIMES FUTURE DEVELOPMENT 


• GRAPHICS/COLOR ANALYSIS CAPABILITY 

• REFINEMENT OF CHIMES MODEL 

• INTEGRATION WITH INTERFACE PROTOTYPING TOOL 

• INTEGRATION WITH REQUIREMENTS ANALYSIS TOOL 


N- 15 


CHI-14 
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TRUST - TDRSS Resource User Support Tool 

Space Network Control Conference, December 1990 

TRUST N 9 2 ’ 1 1 0 
TDRSS Resource User Support Tool 

Thomas P. Spam 
R. Daniel Gablehouse 

Laboratory for Atmospheric 
and Space Physics 

University of Colorado 


Laboratory for Atmospheric and Space Physics I 


I tp* December 12*13, 1*00 


J 
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TRUST - TDRSS Resource User Support Tool 
Space Network Control Conference, December 1 990 


TRUST 

1 DEVELOPMENT CYCLE 





Laboratory for Atmospheric and Space Physics 


rdg, tpe December 12-1 3 1MO 
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TRUST - TDRSS Resource User Support Tool 
Space Network Control Conference, December 1990 


TRUST DEVELOPMENT 


Flight Projects 

• Solar Mesosphere Explorer (SME): Realtime Control and Monitoring: 
Science Planning and Scheduling; TDRSS Scheduling and 
Ground Control 

• Solar/Stellar Irradiance Comparison Experiment (SOLSTICE): 
Science and Mission Planning; Instrument Monitoring, Command 
and Control 


• Ocean Topography Experiment (TOPEX - JPL): LASP Involvement 
Includes TDRSS Scheduling 

• Long Duration Balloon Project (LDBP - GSFC/WFF): LASP 
Involvement includes TDRSS Scheduling and Ground Control 


Study Projects 

• Telescience Implications on Ground Systems, Scheduling Architectures 
Conceptsjand Networks (TIGS SCAN Testbed - GSFC): LASP Involvement 


1 — \ 1 ■ ■ wuiucu - VIUI Ul, LMC 

Includes Planning and Scheduling; Instrument Operations 


0-3 


i Laboratory for Atmospheric and Space Physics 


I rdg, tpa December 12*13, IfSO 
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TRUST - TDRSS Resource User Support Tool 
Space Network Control Conference, December 1990 

Scheduling Window 


12 : 00:00 14 : 00:00 


16 : 00:00 18:00 00 


ONES 

GSTDN 

NOAA 

Orbit events 
S/C events 


FWD LINK 
RTN LINK 
PBK 
TRACKING 

INTERFERENCE 
ORBIT EVENTS 



12 : 20:00 12 : 30:00 12 : 40:00 12:50 00 




— nrnnj 


Laboratory lor Atmospheric and Space Physics I 


rdg.tpe De c ember 12-13, 1M0 
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TRUST - TDRSS Resource User Support Tool 
Space Network Control Conference, December 1990 

ODM/GCMR Window 


CQ QQ ^par proarr U£QatUUQbL, 



1 rrr-MANn -J 

REACO GCTR UNK-rtXt*>RET 


GCM REQUEST 9803. LINK-TCOE-RETIRN 

ppowAon «urDuinrr nfM Of 

hPMtjrovin: nm 

STATUS 

STATUS 

SIGNAL 

SIGNAL 

FREQ 

FREQ 

DOPPLER OCTP: 

OOPfLERCCrP 

PCNsERMOCE. 

PCMERMXt 

CHANNEL ID 

CHANNEL ID: 

WHATEVERELSE. 

WHATEVERELSE 

n 

CSTOL> 



I I 

. ▼ 



VST 


rcnflFQ rer 


iCCf^lGURE TDRS WITH 
bLAY_TO0e (RT/PQK) 


|PHA5£_nOC€ (C0/NC0) 


F0WARD LINK R£ AGO * 

return link re aco * 


Li^ RECONFIGURATION 


FOWARO LINK SWEEP 


INHIBIT DOPPLER 
rrrpg^ATiON 


AU.TVEOTVCRS’UT 


u 


Laboratory for Atmospheric and Space Physics I 


0-6 
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TRUST - TDRSS Resource User Support Tool 
Space Network Control Conference, December 1990 


SUMMARY 


• Generic TDRSS Scheduling with use of the Expert System 

• Automatic Re-scheduling, for conflict resolution, with Expert System 

• ODM/QDM Processing and Constraint Checking 

• Trend analysis of TDRSS link, as an aid to TDRSS Operations 

• Capable of formatting schedule messages, to allow scheduling 
of multiple networks (TDRSS, DSN, etc.) 

• Receives and processes Spacecraft PSAT & Orbital Information 

• Capable of handling several communications protocols (NASCOM, 
SPAN/DECNET, TCPIP, etc.) 


• Supplies planner/scheduler/operator a view of possible activities, in 
the Scientific/Mission Context (X Window Based) 

• Menu driven GCMR, Schedule Requests & Processing, if desired 


Multi Spacecraft Capability 


Written Entirely in Ada 

Laboratory for Atmospheric and Space Physics i 


rdg, ip* December 12-13, 1 WO 


0-9 
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Network Control Center 
User Planning System 
(NCC UPS) 


Brian Dealy 

Computer Sciences Corporation 

December 1990 


Space Network Control Conference on 
Resource Allocation Concepts and Approaches 


DSTD 
Code 520 


Agenda 


Ups System Overview 
Scheduling Interfaces 
Graphics scheduling Aid 


00-2 


GSFC / CSC 
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PRECEDING PAGE BLANK NOT FILMED 


DSTD 
Code 520 


UPS Overview 


Hardware / software Configuration 

Unix Platforms running X11R4 and OSF Motif 1.1.1 

Posix compliant with a few exceptions 

Uses TAE Plus 4.1 - 5.0, A GUI builder developed by NASA 

Software to run on various host CPUs 


GSFC / CSC 
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NCC UPS Role 


Replace each of the current Mission Planning Terminals (MPTs) 
as the user interface to the NCC. 

This interface includes: 

- Interactive entry of TDRSS schedule requests 

- Processing of batch request from other systems 

- Transmission of requests to the NCC 

- Receipt of confirmed schedules from the NCC 

- Reporting to users 


00-4 


GSFC / CSC 
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Major NCC UPS Functional Requirements 


Provide input and validation of orbital data 

Provide UPS database management 

Provide interactive and batch input and validation of 
schedule requests 

Provide transmission of SARs to the NCC 

Provide reception of NCC messages and reporting to users 


GSFC / CSC 


00 - ^ 


DSTD 
Code 520 


Interactive User Access Levels 


• The Mission Coordinator: 

- Modifies database definitions 

- Adds and deletes users 

- Enters and modifies static data in the Translation 

- Map and User Environment Tables 

• The Mission Scheduler: 

- Reads orbital data from tape 

- Generates schedule requests 

- Transmits SARs to the NCC 

- Generates reports and queries 

• The Mission User: 

- Generates predefined reports 

- Reviews scheduling information 
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UPS Interfaces 


• The UPS user: 

- Provides ISRs and other supporting data 

- May be one of two types: 

-- Interactive 
- Electronic 

• The NCC: 

- Receives SARs from the UPS 

- Transmits confirmed schedules, rejected requests, and schedule updates to 
the UPS 


83151 ( 7 ) 
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Interactive User Subsystem 


• Supports interactive functions 

- Information window 

- System administration 

- Mission setup 

- Orbital data operations 

- Automatic schedule request generation 

- Specific schedule request generation 

- Mission database maintenance 

- Report generation 

- Database queries 

- Message transmission 


83154 .( 7 ) 
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Interface Navigation 


All Subsystems available from pulldown on information window 

Attempted to limit interface depth to three levels where possible 

Information which has been entered previously should default 
for lower level screens (e.g. start, stop time) 


GSFC / CSC 


00-9 


DSTD 
Code 520 


Scheduling Screen Hierarchy 
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Interactive Scheduling Input Panels 


• Autoscheduling 

- Autogenerate schedule request (autogenerate main panel) 

-- Orbital constraints menu (for adjusting orbital constraints) 

• Specific scheduling 

- Select schedule data (specific main panel) 

- Schedule data tabular display (for tabular scheduling) 

-- Schedule data graphic display (for graphic scheduling) 

- Build specific schedule request (for adding/modifying SARs) 

-- Orbital constraints menu (for adjusting orbital constraints) 

-- Service parameter input panels (for editing respecifiable parameters) 

- SAR validation notice (for saving to database) 

- Bulk modify event (for bulk modifying SARs) 

GSFC / CSC 
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Autogenerate Schedule Request Panel 
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Build Specific Schedule Request Panel 
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Select Schedule Data Panel 


Select Schedule Date I 


Selected Start : 


Selected Stop i ^ 
or Duration : 
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Schedule Data Tabular Display Panel 
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Schedule Data Graphic Display Panel 



Allow single or multiple event mofidication, deletion or insertion 

Present tabular information in an easy to interpret format 

Show interrelationships between services, events, interference 
and intermission conflicts for resources. 

Provide selection / multiple selection via mouse and control key 
Provide visual cues to differentiate TSWs, Events and Interferences. 
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Schedule Data Graphic Display 


• Select/deselect single or multiple requests by clicking on graphic requests 

• Provide action buttons (see select data tabular display panel) 

• Change to tabular scheduling (Table option) 

• Display TSW information for services related to a selected request (from the 
current event information window) 


Select display range based on viewed time 

- Select range of display using Radio buttons 

- Select start time using Viewed Start input field 

- Input Viewed Stop to override the timeline radio button set (optional) 
“ {jgjjjjj bSton C dlsp ay to incor P° rate changes using Update Sraphic 

" GrajJic display configuration depends on the number of missions 
and TDRSs used 

-- Scroll graphic display using the slider mechanism 
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SPIKE: Al SCHEDULING TECHNIQUES 
FOR HUBBLE SPACE TELESCOPE 


Mark D. Johnston 


GSFC 

13 December 1990 


Space Telescope Science Institute • Advance Planning Systems Branch 
3700 San Martin Drive Baltimore MD 21218 
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Domain 

Hubble Space Telescope (HST) observation scheduling 

• HST launched by NASA in April 1990 

• 15 year lifetime, low earth orbit (95m period) 

• science operations for NASA by Space Telescope Science Institute (STScI) 
at Johns Hopkins Univ., Baltimore 

• HST scheduling is a large problem: 

- -10,000-30,000 observations/year to be scheduled 

- large number of Interacting constraints (-10 per observation) 

- operational 

- resource 

- scientific 

- enormous range of constraint timescales (seconds to many months) 
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HST Constraint Timescales 


1 hour 1 day 1 month 1 year 

U, j. ‘ 

1 minute 10 100 1,000 10,000 100,000 1,000,000 

Spacecraft A Instrument setup/changeover times, TDRS 
communications windows 


H Ortltal constraints: occuitat Ion, earth shadow, 
etc. 
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HST Scheduling 

• Predictive scheduling is required by design of spacecraft, ground system 

• Pool of observations is intentionally oversubscribed (by about 20%) 

• Primary goal is to maximize scientific efficiency of observatory 

- maximize utilization on highest-priorlty science 

- maximize quality of data taken 

• Uncertainty is major problem (orbit, availability of guide stars) 

• Spike is a task-oriented scheduler developed by STScI 

- Development started early 1987 

- Current focus: long-range scheduling (one year or more) to resolution of -days 

- Spike is currently operational and working on flight schedules for period 
following on-orbit checkout 

Long-term scheduling is on hold pending revision of observing proposals for 
spherical aberration 
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Spike Overview 


• Spike draws on two major themes In Al research & applications: 

- constraint satisfaction techniques (search, constraint preprocessing) 

- weight-of-evidence combination for uncertainty reasoning 

• Several strategies adopted to decompose problem 

• Data flow schematic: from observing proposals to command loads 



• Spike was designed to support two major modes of use: 

- automatic (offline) scheduling 

- graphical interaction by users, to make scheduling decisions and diagnose 
scheduling problems 
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Spike Architecture 


• Spike Architecture: 

- low-level constraint representation & propagation 

- higher-level strategic scheduling (search) modules 


L 


> scheduling decisions (do, undo) 
• execution feedback 

• constraint modifications 


• scheduling possibilities 


- preferences for scheduling times 



Strategic 

Scheduling 

Level 


Constraint 
Representation 
and Reasoning 
Level 
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Constraint Representation & Reasoning 


• Temporal constraints and preferences are captured by “suitability functions” based 
on scheduling expert’s assessment: 

the degree of preference for scheduling Aj at t due to constraint a, 

given that A j( A k , ... scheduled at tj, t k is S^ t; t jf t k , ...) 

• Suitability functions are defined for constraints and derived for tasks 

• Projected to functions of time (only) by taking max over possible scheduling times 
of related activities 

• Combined by multiplication: value of 0 means scheduling forbidden, >0 indicates 
degree of preference 

• Combination is formally Identical to weight-of-evidence combination in uncertainty 

reasoning except for special role of overwhelming evidence against scheduling at 
certain times (S = 0) * 
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Suitability Functions (cont.) 


• Task suitabilities are computed by iteration corresponding to: 

node consistency on network of constraints 
-i- implications of cumulative scheduling decisions 

» Value of suitability function informs scheduling agent: 

- times excluded due to strict constraints 

- measure of combined degree of preference due to preference constraints 

• For computational efficiency, suitability functions in Spike are represented by 
piecewise-constant functions of time 

- closed under all important operations 

- no discretization of time or suitability values required 
i.e. no arbitrary limits on time granularity 



Use of Suitability Functions by Scheduling Agent 

• Identify unschedulable activities: S|(t) = 0 for all t 

• Measure of optimality of schedule: pjSj(ti) 

i 

• Measure of potential inherent in partial schedule: 

Yimax S|(t) indicates best that can be achieved 
i 

- use to guide search, l.e. explore most promising alternatives first 

• Explanation: whv an activity Is unschedulable at t can be determined by examining 
contributions of constraints to suitability 

- guide backtracking at deadends 

- give users insight into problem cases: Spike provides graphical display of 
contributions to strict and preference constraints 
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Spike Screen Example 
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Advantages of Suitability Function Framework 


• Mnstraints 8nS f ° r 8lmtiltan90tt8| y presenting strict (yes/no) and preference 

• Framework can represent naturally: 

- trade-offs among preferences 

- uncertainty in predicted scheduling conditions (e.g. high risk => low suitability) 

- implications of scheduling decisions as they are made 

- implications of task execution as schedule is implemented 

Identify inconsistent constraints & unschedulable activities as soon as feasible 

‘ X^hXl'pd^S" Vi0lat ‘° n ° f 8,riCt cons,raints or a consequence of 

• No bias about future scheduling decisions 

• Generally declarative representation => easy to modify 
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Limiting Search & Constraint Propagation 

Techniques used by Spike: 

• Demand-driven constraint propagation 

- i.e. only upon reference to quantities which require constraint consistency 

• Time: schedule from coarser to finer time resolution - 

- Formulate constraints to capture essential behavior at relevant timescales 

- Segment scheduling period into sub-intervals, commit, then decompose 

• Path consistency - 

For some types of binary constraints it is possible to perform path-consistency 
before scheduling 

- dramatically speeds constraint propagation during scheduling search 

- identify oath- inconsistent constraints before scheduling starts 

- drawback: reduced explanatory capabilities 
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Limiting Search (cont.) 


• Activity clustering - 

Sequence activities into clusters to commit as single entities, considering: 

- absolute time constraints 

- binary relative time constraints in path-consistent form 

- heuristics for ordering preferences 

(e.g. constraint strictness, minimize state change overhead times) 

- collapse partially-redundant constraints to their conjunctions 

- puli activity constraints up to cluster level and save 

Path Consistency + Activity Clustering =* 

> order of magnitude reduction in size of problem 
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Scheduling Search 

Several methods provided: all use same underlying constraint 
representation/propagation mechanism: 

• Greedy algorithms 

• Backtracking search 

• Stochastic ("Neural network”) 

• Repair methods 


Preliminary investigation of re-scheduling algorithms conducted (i.e. where 
schedule stability is an important goal) 
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Stochastic Search 

• Developed in collaboration with H.-M. Adorf of Space Telescope - European 
Coordinating Facility 

• Motivated by Hopfield discrete neural network model 

(but can be formulated as backtracking search using network only for bookkeeping) 

• Discretize time: network element represents decision to schedule an activity in a 
time interval 

• Network biases and connections derived directly from suitability functions 


X 
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X 

2 


X 
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Stochastic Search (cont.) 


• Couple to additional networks representing 

- constraint that activity must be scheduled sometime 

- resource (capacity) constraints 

• Approach is well-suited for satisficing search where optimization is desired but 
infeasible 

• Interesting characteristics of search: 

- backtracking from deadends and extending partial assignments are 
simultaneous competing processes 

- tends to maximize overall degree of preference represented by suitability 
functions 

- i.e. schedules tend towards optimal 

- permits temporary constraint Inconsistencies but will not terminate until there 
are none 

- may not converge (stop and restart) 

• By far most effective search strategy in Spike to date 

• Performance demonstrated to be adequate for large-scale HST problem 


P- 16 


190 









Neural Network Search Timings 
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Repair Methods 

• Recent work is concentrating on repair methods 

- analysis of neural network operation has isolated several heuristics that explain 
its success, e.g. min-conflicts 

- theoretical analysis of model problems has identified other heuristics that 
further improve search performance 

• Repair heuristics can be applied in framework that preserves performance of neural 
network but adds flexibility 

• Ideal for reactive rescheduling 

• Machinelearning techniques are being applied to repair methods to “learn" best 
strategies 
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Implementation 


• CommonLisp, old Flavors, conversion to CLOS just completed 

• CommonWindows for user l/F 

• Developed and operated on Tl Explorer Lisp machines 


STSci ether net backbone 



• Unix port of core system & user l/F completed December 1989 (using X-windows 
based CommonWindows); plan for operations migration to Sparcstations over next 
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Status 


• Spike is in operational use at STSci for scheduling the period following HST 
instrument checkout and calibration 

- long-term scheduling has been delayed by optics problems 

- Spike is being used for scheduling feasibility checking on shorter timescales 

• Use on other problems has been demonstrated: 

- Spike now running at UC Berkeley for scheduling NASA’s Extreme Ultraviolet 
Explorer (’92) 

- MIT plans to use Spike for scheduling X-ray Timing Explorer mission (’94) 

• Ongoing work at STSci on performance improvements, repair & rescheduling, 
short-term scheduling, portable version 
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Whv Optimize? 


Optimization of planning, scheduling, and manifesting: 

• Saves Time 

• Saves Money 

• Increases Fulfillment of Mission Goals 
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Searchina a Discrete Confiauration Space 



1 2 3 4 5 6 7 a ft 10 11 12 16 14 16 16 17 16 19 20 21 22 23 34 25 28 ... 
Configuration 


• Configuration space is discrete • Typically, one would want to 

and exponentially large find a good solution by looking 

at about only 100 out of n! 

• Hill climbing is a reasonable possible solutions 

approach, but terms such as “hill", 

“neighborhood", and “direction" 
are not obviously defined 


C 1969 Space Industrie* Interna OonaJ. Inc. 
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Heuristics Algorithms Are Used For Optimization 


• What is a heuristic? 

A rule which usually finds a solution that is good but not 
always optimal 

• Why use heuristics? 

Realistic scheduling problems are NP-Hard 

Finding an exact solution is not realistic 

• Polynomial heuristics are used instead of exponential exact 
techniques to make optimization feasible 
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Use of Heuristic Methods on a Sample Scheduling Problem 


ActMUM 


A 


(Resource Uugi, (1,5) 

Job Time) 
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Use of Heuristic Methods on a Sample Scheduling Problem 

{ Continued) 


Greatest 

Resource 


Scheduling 
Results Using 
Standard 
Heuristic 
Approaches 




Space Industries' Scheduling 
Tools Use Intelligent _ 
Perturbation Heuristics To 
Drive Towards Optimality 
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Intelligent Perturbation Algorithms are Iterative Refinement Techniques 



Unlike these other methods, Intelligent Perturbation Algorithms rely on search steps that 
are “intelligent” rather than random to systematically and quickly find good solutions 
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Properties of a Good Iterative Search Operator 

• Operator should be able to potentially span the search 
space in a small number of steps 


• Computational overhead of iterations should be small 
compared to cost of producing a schedule 


• Search should have a randomized component (or some 
other provisions) for avoiding loops and breaking away from 
local optima 


Q-8 


196 

















SPACE 

INDUSTRIES 

INTERNATIONAL 

INC 




Planning and Scheduling 
Systems and Services 


Intelligent Perturbation Algorithm (Dispatching Example) 

1) Rank activities (tasks, operations) by priority 

2) Create Initial schedule by dispatching using ranked ordering 

3) Adjust rankings using perturbation operator to accommodate 
unscheduled objectives 

4) Create new schedule by dispatching using new ranked ordering 

5) Repeat steps 3 and 4 until search cutoft is reached 

6) Use best schedule found during search 
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Perturbation Operator Attributes (Dispatching Example) 


• Increases rankings of activities not satisfactorily scheduled on the 
previous iteration 


• Increases rankings of bottleneck activities 


- Parameters can be adjusted to fit the structure of the particular 
scheduling problem 


• Choice of parameters is key to finding good schedules 
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Number ol RvrwUoro 


• Standard Methods Give Solutions 23% Worse 
Than Optimum on Sample Test Problems 


• Intelligent Perturbation Search Techniques 
Improve Solutions to Within 10% of Optimum 
In 10 Search Steps 
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Scheduling Implementations Using Intelligent 
Perturbation Algorithms Include: 


• Optimization of scheduling scenarios for SLS-1 and IML-1 
pra/postflight Baseline Data Collection Facility (BDCF) 
sessions by the MIT Man- Vehicle Laboratory 

• Optimization of Space Station Freedom Design Reference 
Mission (DRM) scheduling 

• Optimization of planned operation of customer payloads 
aboard the Industrial Space Facility <ISF) 

• Optimization of ISF-TDRSS command scheduling 

• Optimization of Spacelab Stowage for SLS Mission by GE 
Government Services 

• Optimization of petrochemical plant scheduling by The 
Johnson Group 

In addition, independently developed algorithms used at JPL and NASA AMES 

use directed iterative refinement methodologies 
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Major Advances in Scheduling Capabilities 



1980s 

1990s 

Scheduling 

Optimization 

Iterative Search Techniques 

Parallel Processing 

Scheduling Software 
Development 

Mouse- Window Style 
Interactive User-Friendly 
Interfaces 

Object-Oriented Programming 
Environments 
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The Prototype ISF Experiment Scheduler 
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Industrial Space Facility (ISF) 
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Capabilities 

• Permanent presence In space 


High quality microgravity environment (lO^to 10' 7 g) 
3 to 6 months mission duration 
Power-rich environment 


Applications 

• Microgravtty laboratory 

• Right technology and operations testbed 

• Power source for Space lab and other Shuttle missions 

• Space sciences platform for observation and measurements 

• Platform for attaching external payloads 

• “Interim $tep“ to International Space Station and 
international man-tended free-flyers 

• Processlng/mahufacturing facility 


• Accommodation of stateof-the-art automation and robotics 

• International Space Station rack compatibility 


The first permanent, man-tended commercial space facility designed for 
R&D, testing and, eventually, processing in the space environment. 


C 1 888 sp»c# lndo*tn«* lnt*m«»ona], Inc. 
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Motivation 


The Prototype ISF Experiment Scheduler was developed to: 

• Establish/assess design requirements 

• Assure compatibility among payloads 

• Formulate a pricing policy for the ISF 

• Optimize utilization of scarce resources; limited availability and 
high cost makes optimization critical. Schedules which make 
best use of available resources are typically more satisfying to 
customers because they allow additional experiment runs. 


Flexible and efficient manifesting, scheduling, and operations 
capabilities are central to the customer oriented commercial 
approach of the ISF project. 


C 1M0 Spec* induatn** inUnrntcnal, he. 
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Objectives 


The primary goals of the Prototype ISF Experiment Scheduler 

project were: 

• Development of a prototype multi-variable scheduling tool for 
making manifesting decisions and resource usage assessments 

• Rapid design and implementation of the system in a very short 
time period 

• Building the system with an intuitive and graphical interface 
on a personal computer (Apple Macintosh) 


The number of complex experiments and real-time changing 
constraints aboard the ISF (or many other spacecraft) make it 
virtually impossible for a human scheduler to manually find a 
timeline which simultaneously maximizes the utilizations of 
multiple resources. 


© 1969 Space Indurtrkas IrrtarmUonai, Inc 
Q-17 



SPACE 

INDUSTRIES 

INTERNATIONAL 

INC. 


sp/t&cfifffr 


Planning and Scheduling 
Systems and Services 


The Intelligent Perturbation Algorithm 



Mission Eiapsad Tims 


End of Iteration 1 : Unable to schedule 
Float Zone Crystal Growth Facility due to 
microgravity disturbance during Reboosts. 



Start of Iteration 6: Feasible scheduling 
of both Retjoosts and the Float Zone 
Crystal Growth Facility. System has 
"learned*' proper ordering of activities. 

t 



End of Iteration 5: Unable to schedule 
Reboost due to need for low microgravity 
during Float Zone Crystal Growth Facility. 


End of Iteration 6: 83 payload runs 
scheduled. All activities feasibly scheduled 
at least once with a power utilization of 90%. 


© 1089 Sp4C* tndu»m«t tnUmationai, Inc. 
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Multi-Variable Optimization 


ISF 

Payload 

Scheduling 
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Prototype ISF Experiment Scheduler - Results 


• Allows easy assessment of manifest changes, and comparison of relative 
revenues and resource utilizations among different sets of manifested 
payloads. 


Run time on a Macintosh li is about 45 seconds per iteration. Graphics 
require 2/3 of this time. Typically 30 iterations are suffiaent to generate 
very good schedules. 


• Core of the scheduler was built in a tew days, and the input and output 
interfaces were built in a couple of weeks. 


As the design and operational characteristics of the ISF and Its 
associated peyloads become better defined, this prototype will serve as 
the besis for the development of higher-fidelity tools. 


Initial research has looked at methods of providing dynamic 
rescheduling of ISF telescience operations in rssponse to raaMIme 
investigator requests. 
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Space Station Design Reference Mission Scheduling 

• Crew availability was the limiting factor in the scheduling of this DRM. 

Optimization increased crew utilization by more than 106 hours during the 2 
week mission. 


• NASA recently published a rate of lOOK/crew-hour for commercial 
operations aboard the Space Shuttle. This translates to lost opportunity 
costs of 5.3 million per week If optimization is not used to fully utilize crew 
available for payload operations. 



Runs 

Crew (crew -hr) 

Power * (kw-hr) 

Power** (kw-hr) 

Activity Density** 

Requested 

Available 

NASA Provided Baseline 
Space Industries Beau ft 

422 

272 

387 

539 hr. 10 min (118.1%) 
456 hr, 30 min (100.0%) 
333 hr, 35 min ( 73.1%) 
440 hr, 10 min ( 96.4%) 

11474.7(136.6%) 

9746.3 (116.0%) 
11047.3(131.5%) 

8400.0 (100.0%) 

6685.7 ( 79.6%) 

6673.7 ( 79.4%) 

22.7 

25.0 


* tor the entire schedule 

** in initial 2 weeks only 
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ISF - TDRSS Command Scheduling Demonstration 

• Demonstration scenario conducted over a 24 hour (16 orbit) period 


• 1 6 tasks (some repetitive) were considered 


• ISF power available was limited to 7 kilowatts at any time 


• 2 TDRSS available. TDRSS is accessible 58.9 minutes (65.1%) 

per orbit 


* Downlink via TDRSS is in 1 of 5 exclusive formats. Multiple tasks 
may be performed simultaneously as long as they do not require 
differing formats. 


Almost all tasks had unique and complex constraints which could not 
easily be accommodated using a standardized input interface. 

Required a radically different approach to representing 
constraints and building a schedule. 


0-?3 
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Planning and Scheduling 
Systems and Services 


Example Task: Communications Check 


Duration: 10 minutes, consisting of 5 consecutive 2 minute segments 


Power Requirements: 200 W for the full 10 minutes 


Downlink Requirement: Each of the 5 segments must be in a different 
format (A f B, C, D, and E) so that each format is used once. The order is 
not important. 


Repltltlons: Should occur (i.e., the starting time should fall) once per 
orbit (as measured from time zero). 
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Planning and Scheduling 
Systems and Services 


ISF - TDRSS Command Scheduling Demonstration - Orbit 6 


»• II 12 13 14 13 IftO/M con 7 33707 1033 


TDRSS FORMATS 

format n n 

FORMAT n o 

FORnm C Q 

format o id 

FonrtRT t q 
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Planning and Scheduling 
Systems and Services 


Conclusions 


• intelligent Perturbation Algorithm approaches have been 
successfully implemented in numerous scheduling systems 


• Optimization can result is significant cost savings and can 
maximize capabilities when resources are limited 


• Successful implementation of a scheduling system requires 
an in-depth understanding of space operations, optimization 
techniques, and building user-friendly software that is 
intuitive and easy to use 


0-26 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Need and Viability of 
Polynomial Time Techniques for SNC 

• Need for Efficient Scheduling Techniques such 
as Polynomial Time Algorithms 

Subjective scheduling decisions in an environment such as the 
SN are necessary. However, producing a good initial schedule 
based on subjective analysis is very labor intensive, impractical 
and unnecessary. Initial schedules based on computationally 
efficient approaches optimizing a general objective such as 
maximizing requests can be the basis from which a final schedule 
can be evolved through changes and fine tuning based on 
subjective analysis and human interaction. 

• Viability of Polynomial Time Algorithms for SNC 

Recent R & D effort at GSFC has shown that polynomial time 
algorithms for SN resource scheduling are viable and practical. 

S Reddy 3 — — GSFC / CSC — 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

An Intrinsic Characteristic of 
SN Scheduling Problem 

Highly-coupled usage of resources for each request, 
i.e., Each request uses all resources it requires 
either simultaneously or in the immediate time frame 


Request Window 


Request Duration 
Resource 1 Usage 
Resource 2 Usage 
Resource 3 Usage 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 


Expected Characterist ics of the Schedule 

Tight coupling of resource usage tends to force 
schedules with the following characteristics 

. General sequence (time-order) of scheduled 
requests is nearly same for all resources 

. Schedule for high-demand resources implicitly 
control the schedule for resources with low - 
demand 

A multiple resource-usage request which is rejected 
when attempted to be scheduled independently on a 
low demand resource type is highly unlikely to be 
scheduled on a high-demand resource type. 


S Reddy 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocati on Concepts and Approaches 

Optimization Based Sche duling Approach 

A combination of optimization and heuristic techniques 


• Optimal and near optimal single resource 
scheduling using polynomial time optimization 
algorithms 

• Heuristic reasoning for decomposing multiple 
resource problems into a series of single resource 
problems suitable for application of the 
polynomial time single resource algorithms 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Single Resource Algorithms 

• First Algorithm (Does not consider activity priorities) 

— Maximizes the number of scheduled activities 

— Generates sequence of scheduled activities with reduced 
windows 

— Developed earlier last FY under SEAS task 20-122 

• Second Algorithm (Considers activity priorities) 

— Maximizes the priority weighted number of scheduled 
activities when there are two priorities 

— For problems with > 2 priorities, algorithm is applied to 
series of two priority problems 

— Generates sequence of scheduled activities with reduced windows 
S Reddy 7 GSFC / CSC — 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 


First Single Resource Algorithm 


) 1 Activity Window 


Provides . . . 

Optimal Solution 
when windows exhibit 
(Cascade Structure) 


— — Activity Duration 
Activity Flexibility 

1 



Optimal Solution 
when windows exhibit 
(Triangular structure) 



Near Optimal Solution 
when windows exhibit 


A general unrestricted structure 

o 1 n 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Second Single Resource Algorithm 


Provides optimal solution for a two priority 
problem when activity windows within each 
priority are non-overlapping 


Activity Window 
Activity Duration 
Activity Flexibility 


GSFC / CSC 


POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 


Decomposition of 
Multiple Resource Problems 


Schedule resources in increasing order of usability 


Reason: 

Given: 


Resources A and B 

Activity set S(A) — Schedulable only on A 
Activity set S(B) — Schedulable only on B 
Activity set S(A or B) — Schedulable on A or B 


Scheduling as many of activities in S(A or B) as possible 
on least usable of A and B tends to maximize the 
availability of resources for highly resource specific 
activities 


S Reddy 


GSFC / CSC 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Decomposition of 
Multiple Resource Problems 

(CONTINUED) 

Example: S(A) = 100 S(B) = 20 S(AorB) = 20 
Scenario 1 — Schedule A first and schedule B second 

70 of S(A) and 10 of S(A or B) scheduled on A 
20 of S(B) and 10 of S(A or B) scheduled on B 
Total scheduled: 100 

Scenario 2 — Schedule B first and schedule A second 

20 of S(B) and 19 of S(A or B) scheduled on B 
90 of S(A) scheduled on A 
Total scheduled: 129 

Scenario 2 maximizes the scheduled activities 

S Reddy 11 GSFC/CSC — 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Prototype Capabilities 

Scheduling of Specific and Generic Requests for: 

• Tracking and Data Relay Satellites 

• Deep Space Network 

• Ground Network 

• For Combination of Space and Ground Resources 

*— S Reddy 212 GSFC / CSC — 


R-12 


POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVrTY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 


Prototype Test Results 



Total 

Reqstd 

Events 

Scheduled 

Upper 

Wall 

Clock 

First Algorithm (Disregard Priorities) 

Events 

Bound 

Time 

(Min.) 

1584 

1478 93.3% 

98.7% 

3 .25 


2960 

2415 81.6% 

86.% 

21.1 

Second Algorithm (Consider Priorities) 

1594 

1499 94.6% 

98.7% 

18.5 


Tested on 

• PC/AT running at 12 MHz without a math coprocessor 
S Reddy 13 GSFC / CSC — 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Computational Characteristics 

Analytically determined computational 
requirements of the prototyped algorithms is a 
3rd order polynomial of the number of activities 

t = k * n 3 

For n=1584 

t = 3.25 implies k = (1584) 3 *(3.25) 

For n = 2960 

t= (1584) 3 * (3.25) * (2960) 3 =21.2 Min 

S Reddy 2 1 3 GSFC / CSC — 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 


Prototype Characteristics 

• COMPUTER: PC or PC (AT) 

• LANGUAGE: MS-FORTRAN 

• NUMBER OF LINES OF SOURCE CODE : 2000 Approx. 

• EXECUTABLE MODULE: 520 Kbytes 

• CAPACITIES: 8 Resource types 

10 Resource Groups (TDRS/Ground Stations) 
12000 Resource Intervals 
3200 Instances 


*— S Reddy 15 GSFC / CSC — 1 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 

Some Features of 
Prototyped Algorithms 

Prototyped algorithms can be used for: 

• Initial batch scheduling 

• Batch rescheduling while limiting changes to any combination of: 

— restricted deletions for selected instances 

— restricted non-deletion schedule changes to selected instances 

— allowable deletion of selected instances 

— S Reddy 214 GSFC / CSC — 1 
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POLYNOMIAL OPTIMIZATION TECHNIQUES FOR ACTIVITY SCHEDULING 
Space Network Control Conference on Resource Allocation Concepts and Approaches 


Some Related GSFC References 


• Optimization Based Prototype Scheduler 
DSTL-90-024, Available December 1990 

• Single Resource Scheduling with Ready and Due Times 
DSTL - 89 - 024, December 1989 

• A Study of Optimization Techniques for Activity Scheduling 
DSTL -89 -01 9 


L- s Reddy 17 GSFC / CSC 
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Range Scheduling Aid 
(RSA) 


J. R. Logan and M. K. Pulvermacher 
13 December 1990 


MITRE 

S-l 


Satellite Control Network 


COMMUNICATIONS 

SATELLITE 



S-2 
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Range Scheduling - Current Approach 


PAPER SCHEDULING CHART 



REQUESTS FOR SATELLITE 
CONTACTS, OTHER SERVICES MITRE 


MITRE Tasking 

• "Investigate the feasibility and utility of developing a 
knowledge-based scheduling aid..." 

• Approach: 

- Replicate current scheduling in automated 
environment 

Develop prototype with user interaction 
Create user-friendly, graphical interface 


S-4 


MITRE 
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Range Scheduling - New Approach 






SATELLITE 

CONTROL 

NETWORK 


AUTOMATION 

UPGRADE 


REQUESTS FOR SATELLITE 
CONTACTS, OTHER SERVICES 


MITRE 
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RSA Features 


• Graphical User Interface 

- Similar look and feel to paper based approach 
— Real-time response to schedulers 

• Constraint Based Analytical Capability 

- Provides scheduling tools 

— Automates scheduler heuristics 

• Multi-user 

- Architecture supports real-time multi-user capability 

• Portable 

- Sun, Symbolics, Tl Explorer, and Mac II 
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Range Scheduling Aid Display 
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Constraint Based Analytic Capability 


• Conflict Identification 

- Oversubscribed resources? 

• At local Remote Tracking Station 

• Across AFSCN 

- Adequate turnaround time 

• Conflict Explanation 

- Type of conflict 

- Specific resources and times associated with conflict 


S- 10 


MITRE 
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Constraint Based 
Analytic Capability (concluded) 


• Conflict Resolution 

- For single task (list of possible solutions) 

- Globally across time slice 

• Error Checking 

- Satellite visible? 

- In requested time window? 

- At proper RTS? 


MITRE 

S-ll 


RSA Architecture 




* 


s 

EXTERNAL 

SYSTEMS 

INTERFACE 
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Range Scheduling Aid Benefits 


• Automated scheduling 

• Electronic schedule dissemination 

• Simultaneous scheduling 

• Extensible system 

• Reduced training time 

MITRE 

$- 1 J 
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N92-11 058 


SCHEDULING TECHNIQUES IN 
THE 

REQUEST ORIENTED SCHEDULING ENGINE 

(ROSE) 

December 13, 1990 


David R. Zoch 
Tela mall: DZOCH 
Phone: 805.0457 


SEAS 

Systems, Engineering, end Analysis Support 


T-l 



AsroSyt 


Agenda 


J 


• Introduction to ROSE 

• NCC-ROSE (test results) 

• ROSE Scheduling Approach 

• Scheduling Techniques 

• Summary 


GSFC Contacts for ROSE Projects; 

G. Mike Tong (Code 520) ATR for ROSE* Ada 
Larry Hull (Code 520) 

Nancy Goodman (Code 520) ATR for NCC-ROSE 
Sylvia Sheppard (Code 520) 


SEAS 

Systems, Engineering, and Analysis Support 


SeroSys 


T-2 
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ROSE Summary 


scheduling ^ssumi suchM^' 1 " 0 ,001 th8t ha# demon9,rated v,abl « solutions to difficult 
Fast, automated, conflict-free schedule creation (> 4,000 request/hour @ 2,000 req's.) 
^i^am»rnem through post-processing: Best First Search for Schedule 

- Rescheduling / contingency scheduling techniques 
Operator tools for computer-assisted scheduling (graphical Interfaces, etc.) 


The ROSE effort involves the cooperation of experienced users, operators and 
implementors of spacecraft data systems 1 

The ROSE effort has had positive Impacts far beyond its original scope 


SEAS 

Systems, Engineering, end Analysis Support 


fferoSyt 



ROSE History 


1SS7 (FORD) 

Teieacience Implication* 
on Ground System* 
mGS) 


1S66 (SEAS / Loral) 
Integrated Resource 
Scheduling Teak 
(Distributed Scheduling) 


IMS (SEAS /Lorsl) 
NCC Scheduling 
Prototype 


19S9 (SEAS /Loral) 
- Continued 


Porting Study 


IMS (SEAS / CSC) 
SCAN Teet Bed 
Prototype COOS 


1SS9 (SEAS / Loral) 
Comparison Study 
Report Releas e d 


1 M0 (SEAS / Loral) 
•Port to Ada 
(Rose* Ada ) 


1 W0 (SEAS/CSC) 

SCAN Testbed 
(EOS) 


1W0 (SEAS / Loral) 
Continued 
Enhancement 


SEAS T 

Systems, Engineering, and Analysis Support 
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NCC - ROSE Task Goals 


• Prototype a viable generic NCC request scheduling process with predicted load levels 
for the 1995 timeframe using: 

- Existing ROSE prototype 

- Different request selection and placement strategies 

- Different scheduling algorithms 

• Use requests that represent a realistic contention for TDRSS resources with realistic 
view periods 

• Prototype required user request flexibility 

• Evaluate FERN language for use In the NCC environment 

• Determine tradeoffs between success rates and time-to-schedule for different 
scheduling algorithms 


SEAS 

Systems, Engineering, and Analysis Support 


Rerolyt 


Accomplishments 


Verified ability of FERN to represent realistic generic requests by building and 
scheduling generic requests: 

- 31 Generic user requests 

- 11 Missions 

- Requests for 1 645 activities per week 

- Realistic TORS view periods 

- Realistic resource contention 

Prototyped and compared scheduling architectures 

Results documented In Scheduling Results Analysis Report for the NCC Prototype 

Able to schedule over 94% of anticipated requests for week long schedule in 1995 In 
less than 2 hours 


SEAS 

Systama, Engineering, and Analysis Support 
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Sytltmt, Engineering, end Analysis Support 
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1 Users submit requests tor services at a specific time 

2 INITIAL SCHEDULING (2 hours) - An Initial schedule Is created by computer 

3 CONFLICT RESOLUTION (3 to 5 days) - operators phone users and ask 

- what Is the type of event? (orbit adjust, tape dump, etc.) 

- can request be shortened? 

- can request be moved? 

- can request use a downgraded service (MA vs. SA) 

- can request use the other TDRS? 

- If neither conflicting user is flexible, choose the higher priority one. 

4 Operators schedule PM and tests (hard ware /software upgrades) around user requests 

5 If there Is a conflict with a user, do the conflict resolution process 
SEAS 

Systems, Engineering, and Analysis Support 

T-9 


LOQAL 

HeroSy* 


ROSE Approach 


1 Users and Op 

alternatives 


lit flexible requests ’ 


2 INITIAL SCHEDULING (1 to 2 hours) - An Initial schedule is created (without conflicts). 
Some requested events are not scheduled 

3 CONFLICT RESOLUTION (2 to 5 hours) - Algorithms that imitate the human conflict 
resolution process are executed to try to schedule the non-scheduled requests 


4 (done) 


5 (done) 


SEAS 

Systems, Engineering, and Analysis Support 
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BFSSE Overview 


Start with an Initial conflict-free schedule and some un-scheduled requests 

Identify png un-scheduled request that you would like to try to schedule 

The algorithm executes the following three steps repeatedly as needed until either a 
solution is found or a timeout occurs 

- SELECT 

Find places on the schedule where the request almost fits. 

- MOVE 

Determine what requests need to be moved to schedule the unscheduled request 


Repeat the SELECT and MOVE steps for all moved requests 


SEAS 

Systems, Engineering, end Analysis Support 
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BFSSE Example 


• Goal Is to add request *’A" to the existing schedule shown below 


Three potential times for request "A" are shown 


□ 


m 


□ □□ 


Mission 1 


Mission 2 


Mission 3 


* It is known that "A" cannot be scheduled anywhere If the rest of the 
schedule remains as is. 


SEAS 

Systems, Engineering, and Analysis Support 


LORAL 



BFSSE Example (cont'd) 




J-K-L M-N 



<= Heuristics for 
Picking Times 


<== Heuristics for 
Selecting which 
activities to move 


2- . r 


{ 7 ^ Attempt to Schedule X 
I y / Z k Schedule Y at time Z 


C - D - e| D®l 0te C, D, and E 


SEAS 

Systems, Engineering, and Analysis Support 
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Summary 


ROSE has shown to be an effective scheduler for solving the types of scheduling 
problems faced by the NCC a 


The ROSE approach fully supports the NCC operations scenario 

Conflict-free schedules can be created in 2 to 4 hours instead of 3 to 5 days. 

ROSE can create schedules quickly enough that alternative contingency schedules are 
possible 

The ROSE conflict resolution strategy utilizes flexibilities in user requests to reduce 
conflicts 


SEAS 

Systems, Engineering, and Analysis Support 
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N9 2- 11 059 


Managing Temporal Relations 
in the MAESTRO Scheduling System* 

Daniel L. Britt 

Martin Marietta Information Systems Group 
303 - 977-4491 


‘Based on the paper Managing Temporal Relations, coauthored with 
Amy L. Geoffroy and John R. Gohring, which appears in: 
"Proceedings of the Goddard Conference on Space Applications of 
Artificial Intelligence". May, 1990, NASA GSFC, Greenbelt MD. 


Space Network Control Workshop. 
Goddard Space Flight Center 
Dec 12413. 1990 
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Managing Temporal Relations in the 
MAESTRO Scheduling System 
Dan Dntl 



INTRODUCTION 


Scheduling defined 

Why scheduling is hard 

Scheduling domains are information-rich 

An effective scheduling approach - Use as much information as possible 
while keeping the computational workload manageable 


MAESTRO adhers to this principle via resource opportunity calculation and 
temporal constraint propagation 

How MAESTRO manages temporal relations 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12413, 1990 
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Managing Temporal Relations in the 

MAESTRO Scheduling System 

Dan Brin 1 
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DEFINITIONS 


Activity - A sequence of operations, steps or subtasks which, when 

executed, accomplishes one or more goals. Each activity has 
associated resource, conditions, state, and timing 
requirements, all of which must be met for the activity to 
accomplish its goal(s). 


Scheduling - The specification of start and end times for subtasks 
making up activities, and the specification of resources 
to be used for each, if there are choices among them. 


Viable Schedule - A timeline of activity performances on which all of 
the performances can successfully be executed, 
given the truth of the assumptions upon which that 
schedule was based. 


Space Network Contnot Workshop. 
Goddard Space Flight Center 
Dec 12413, 1990 
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Managing Temporal Rotation* m the 
MAESTRO Scheduling System 2 

Dan Brrtl 


Activity ATMOS - Atmospheric Spectroscopy 



^^^esources 

subtasks'^^ 

ATMOS 

instrument Power 

Data Vibration 

Sun excl 
angle 

Day/night 

A 1 - Power up 

X 

100 w 




A2 - Self test 

X 

100 w 

4 kbps 



A3 - Calibrate 

X 

250 w 

1 kbps 



A 4 - Repoint 

X 

400 w 

causes 1 000 pg 



AS - Collect Data 

X 

200 w 

2 kbps < 650 pg 

> 32 deg 

daylight only 

A6 - Power Down 

X 






Temporal Constraint - Sutrtask A5 must start 2 - 5 minutes after SOLAR subtask S4 starts 

Placement Preferences - Frontload, maximizing subtask durations and minimizing delays between subtasks 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12413, 1990 
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WHY SCHEDULING IS HARD 


1) Desirability - Difficulty in determining when you've got a good 
schedule, given that different people, agencies, etc. have differing 
goals and priorities. 

2) Stochasticity - Unpredictability in the domain that makes predictive 
scheduling problematical. 

3) Tractability - Computational complexity of the domain, the "size" 
of the scheduling problem. 

4) Decidability - It may be provably impossible to find an algorithm 
which produces an optimal schedule, depending on the definition 
of optimality chosen. 


H. Van Dyke Parunak - "Why Scheduling Is Hard (And How To Do It Anyway)", 
Proceedings of the 1987 Material Handling Focus (Research Forum), Georgia 
institute of Technology, September 1987. 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12413, 1990 




Managing Temporal Relations m the 
MAESTRO Scheduling System 4 

Dan Brtti 



TRACTABILITY 


Scheduling - searching a large, many-dimensional problem space, throughout 
which are scattered viable schedules. 

Given 100 activities using any of 100 resources and starting at any of 100 times 
this space contains aproximately io 300 000 possible schedules. 

Viable schedules make up a tiny percentage of all schedules. 

"Good" schedules can constitute a small fraction of all viable schedules. 

Optimal schedules can make up a small percentage of all "good" schedules. 


Space Network Control Workshop. 
Goddard Space Flight C enter 
Dec 12A13. 1990 
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SCHEDULING DOMAINS ARE INFORMATION-RICH 

Activity structure 

Activity temporal constraints 

Resource types, use functions, availabilities 

Preferences in activity placement, resource use, etc. 

Schedule evaluation criteria (subjective) 

Ways contingencies happen & can be dealt with 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12&13, 1990 
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AN APPROACH TO SCHEDULING 


Represent all available domain information to scheduling system 


Perform computations which analyze input info and synthesize 
other info while not incurring unacceptable overhead 


Use domain info and synthesized info to incrementally make 
decisions which remove "bad" schedules from the search space 
while keeping "good” ones 


Do not allow representable constraint violations, ruling out the 
vast majority of the search space implicitly 


Space Network Control Workshop, 
Goddard Space Fbght Center 
Dec 12413, 1990 
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Managing Temporal Relauons m I ho 
MAESTRO Scheduling Syslem 
Dan Bnrt 
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The preceding information 
useful information: 




THE MAESTRO SCHEDULING SYSTEM 


Opportunity Calculation finds all places on a current partial schedule 
wherein each subtask can be executing w/resp to resources, 
conditions, states and time windows 


Temporal Constraint Propagation uses this & other constraint info 
to specify time windows from which subtask starts and ends can 
be chosen such that a whole activity can be placed 

An activity is selected to be scheduled using these results and 
user-specified criteria indicating importance of various heuristics 

Selected activity is placed on the schedule using results of 
constraint propagation and placement preference info 

User can select activity to schedule and/or can place selected activity 
using results of above computations 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12A13. 1990 
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Managing Temporal Relations m the 
MAESTRO Scheduling System 
Dan Britt 
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CONSTRAINTS ON THE PLACEMENT OF A SINGLE ACTIVITY 


A. Resources and conditions 

B. Time windows 

C. Activity structure 

1. durations and delays, with variability 

2. nonadjacent subtask relations, activity duration 


Space Network Control Workshop, 
Goddard Space V light Conter 
Dec 12413, 1590 
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Managing Temporal Relations in the 
MAF ST RO Scheduling System 1 2 

Dan Bntl 
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CONSTRAINTS BETWEEN ACTIVITIES 


A. Precedes, follows, starts, ends, and conflicts, with variable offsets 


B. One-way versus two-way constraints 


C. Constraint arities 


D. Relations to events and to absolute times 


Space Network Control Workshop. 
Goddard Space Flight Center 
Dec 12413, 1990 

U~ 
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MALSTRO Scheduling System 13 
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Soft Constraints 

A. General preferences 

1 . loading 

2. durations and delays 

B. Specific preferences 

1 . maximize one duration 

2. place subtask near to or far from a subtask, event or time 

C. Random placement 

D. User placement 


Space Network Control Workshop, 
Goddard Space Flight Center 
Dec 12413. 1990 
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Managing Temporal Reunions m ihe 
MAESTRO Scheduling System 
Dan Bntt 


CONTINGENCY HANDLING 

A. Schedule late-arriving request 

B. Unschedule (bump) to fit new request 

C. Unschedule to reflect resource availability changes 

D. Interrupt and restructure an activity in real time 


Space Network Control Workshop. 
Goddard Space Rig* Center 
Dec 12413. 1990 
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Managing Temporal Relator* in the 
MAESTRO Schedukng System 
Dan Britt 
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Resource Representation in COMPASS 


Barry R. Fox 
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Introduction 


COMPASS is an incremental, interactive, non-chronological 
scheduler written in Ada with an X-Windows user interface. 
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Introduction 

Incremental 

beginning with an empty schedule, activities are added to 
the schedule one at a time, taking into consideration the 
placement of the activities already on the timeline and 
the resources that have been reserved for them. 

Interactive 

the order that activities are added to the timeline and 
their location on the timeline are controlled by 
selection and placement commands invoked by the user. 
Non-Chronological 

the order that activities are added to the timeline and 
their location are independent 
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Introduction 


3a 


COMPASS is the successor of Wedge (1986), a scheduler of 
similar capability written in Lisp on a Symbolics machine. 

COMPASS contains portable, generic packages that were 
useful and necessary in the conversion of a major Lisp 
program to Ada 
Lookahead I/O 
Stream Oriented I/O 
Symbol Data Types 
Generic List Package 

COMPASS can be useful to anyone planning the conversion 
of software that relies heavily upon lists and symbol data types. 
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Statement of the Problem 

An activity can be performed only if all of its required 
resources are available in sufficient quantity for a sufficient 
duration of time. 

A schedule must arrange activities so that the combined 
resource requirements at any point in time do not exceed 
the resource availability. 


Statement of the Problem 

Implementation of interactive and automated scheduling 
systems requires 

an external (textual) representation for resource requirements, 
an internal representation for resource requirements, 

an external (textual) representation for resource availability, 
an internal representation for resource availability, 

an algorithm for placing activities on the timeline so that 
the combined resource requirements at any point in time 
do not exceed the resource availability. 


y-io 
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Statement of the Problem 


6 


NASA requires access to advanced scheduling technology. 

Basic scheduling data structures and algorithms should 
be publicly available "textbook" knowledge. 

This enables traditional "time and space" analysis of 
proposed methods. 

This enables objective comparison of methods, unobscured 
by differences in implementation languages and hardware. 

This enables the creation of new scheduling applications 
without the costly process of re-discovery and re-invention. 





Representation of Resource Requirements 


Resource requirements can be classified by the properties of the 
function that defines the quantity required at each point in time. 

Location of the origin 

Shape and continuity 

Sign 

Extent 


V-l? 
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Representation of Resource Requirements 


8 


COMPASS represents resource requirements by piecewise 
linear functions. 



The origin is relative to the beginning of the activity. 

Positive quantities represent the amount required by an activity. 
Positive segments with finite extent represent assignment. 
Positive segments with infinite extent represent consumpution. 


f 

Representation of Resource Requirements 

COMPASS represents resource requirements by piecewise 
linear functions. 



The origin is relative to the beginning of the activity. 

Negative quantities represent the amount provided by an activity. 

Negative segments with finite extent represent . 

Negative segments with infinite extent represent production. 


V-14 
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Representation of Resource Requirements 


This representation is suitable for a wide variety of resources 
including: 

electrical, thermal, communications, etc. 
water, oxygen, hydrogen, nitrogen, etc. 
crew members 

screwdrivers, hammers, pliers, etc. 

replaceable parts, packaged food, disposable clothing, etc. 

storage capacity 

mass and volume 
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Representation of Resource Requirements 


9b 


COMPASS provides a dotted notation for resource names 
which enables "wildcard" resource requirements. 

Given four crew members named: crew.so.bob 

crew.so.carol 

crew.ss.ted 

crew.ss.alice 


request 

crew.ss.ted 

crew.so 

crew 

instances 

crew.ss.ted 

crew.so.bob 

crew.so.carol 

crew.so.bob 

crew.so.carol 

crew.ss.ted 

crew.ss.alice 
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Representation of Resource Requirements 

Piecewise linear functions are represented as an ordered list 
of segment descriptors: 


Quantity-2 
Quantity- 1 


| ''/ V ;'' 1 V ' 1 ' 


Time-1 


Time-2 


( Quantity- 1 Quantity-2 ) / [ Time-1 Time-2 ] 


Representation of Resource Requirements 


ililMl 


( 1 . 0)/[0 1 : 00 ]; 


(1.0)/[0 +inf] ; 


(0.0 1.0)/[0 1:00] (1.0)/[1:00 +inf] 


lli fill 1 1 1' 1 .' . * 1 1 j. 


(1.0)/[0 0:15] (2.0)/[0:30 1:45]; 
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f 

Representation of Resource Requirements 



Notation for time: 


1 

1/2 

1/2:03 

1/2:03:04 

2:03 

2:03:04 

12/31/1990 

12/31/1990@ 2 

12/31/1990 @2:03 

12/31/1990@ 2:03:04 


1 day 

1 day, 2 hours 
1 day, 2 hours, 3 minutes 

1 day, 2 hours, 3 minutes, 4 seconds 

2 hours, 3 minutes 

2 hours, 3 minutes, 4 seconds 
December 31,1 990 
December 3 1 , 1990 at 2:00 
December 31, 1990 at 2:03 
December 31, 1990 at 2:03:04 


V (32 bit internal representation: +/- 65 years at resolution of 1 second) j 

_ / 
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Representation of Resource Requirements 



Piecewise linear functions are represented by linked lists of 
<ramp>/<interval> pairs created using the generic list package. 

(0.0 1.0) /[0 0:15] (1.0 0.0)/ [0:15 0:30]; 





— 

1 



— 

► 










0.0 

1.0 




1.0 

0.0 








0 

0:15 






0:15 

0:30 
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Total memory required is proportional to the amount of detail, 
not to the span of time! 
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Representation of Resource Requirements 


13a 


Given Ada’s ability to create dynamically sized arrays, 
it is feasible to represent lists as both linked lists and arrays! 

However, this is safe only if the compiler correctly implements 
unchecked deallocation! 

( 0.0 1 . 0) /[0 0 : 15 ] ( 1.0 0 . 0 )/ [ 0:15 0 : 30 ] ; 
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Representation of Resource Availability 

COMPASS represents resource availability by piecewise 
linear functions. 



Algorithm for Activity Placement 


15 


To schedule an activity 

locate a time where its resource requirement can be satisfied 

schedule the activity to occur at that time 

translate its resource requirement to that time 

subtract its resource requirement from the resource availability 



Algorithm for Activity Placement 


Subtraction of the resource requirement from the resource 
availability ensures that the resource requirement will be 
satisfied even after other activities are added to the timeline. 

Subsequently, another activity can be scheduled to occur at 
the same time only if its resource requirement can be satisfied 
by the remainder. 

The reversibility of this method for resource reservation 
enables us to "unschedule” an activity by adding its 
resource requirement back into the resource availability! 
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Algorithm for Activity Placement 


17 


To locate where a resource requirement can be satisfied 

locate where each segment of the requirement can be satisfied 
normalize the results and combine by interval intersection 
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Algorithm for Activity Placement 



To locate where a segment of a requirement can be satisfied 
Begin by assuming that all of time is satisfactory 
Consider each segment of the resource availability 
If there is a subsegment which is not satisfactory 
then exclude it from the answer. 



I H 
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Work in Process 


19 


This same algorithm for computing feasible intervals of time 
can be used for pattern matching against other numeric data, 
like latitude, longitude, light and dark, which can be 
reasonably approximated by piecewise linear functions. 


(Special notation needs to be introduced in order to represent 
conjunction and disjunction.) 
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Work in Process 

Few resources can be accurately modeled as quantity available 
over time. 

Rather than building more complex, domain specific models 
into COMPASS, we are building a distributed system of 
schedulers and resource managers that communicate with each 
other through a stylized protocol of requests and reservations. 

Interprocess communication is greatly facilitated by the 
stream oriented I/O facilities already part of COMPASS. 

Development of the basic capabilities is being performed 
jointly with the COOPES project. Specific resource models 
are being developed under the MDC IR&D program. 
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Full Activity Representation 


Act ivity 
Name 
Priority 
Value 
Penalt y 

Predecesor^List 

Successor_list 

Non_ConCurrent_Act ivityList: 

Tempora l_Cons t raint_Iji st 

Durat ion 

Ear 1 iest_Start 

Latest_Finish 

P r e f er red_I nter val_l ist 

Requi red_Resources 


Required_Condit ions 

Act i vit y_End 


Crystal . Step_2 
10 

5000 

1000 

(Crystal .Step_l) 


() 

() 

[Start of * <- Finish of Crystal. Step 1 + 0:15 

1 : 15 


3/00:00 
3 / 12 : 00 

[3/04:00 3/05:30] [3/07:00 3/08:30] ; 

Crew (1-0) / [0 1:15] ; 

Electricity (5.5)/[0 0:15] ( 9-0) / [0:15 

Thermal <5.5)/(0 0:15] (14.0)/[0:15 

M i c r oG ravity T / [ 0 : 1 5 1:00] ; ; 


1:15] ; 

1:15] ; ; 
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( 2 

Conclusion 

The COMPASS code library is a cost-effective platform for 
the development of new artificial intelligence applications that 
must be delivered in Ada and X-Windows. 

It implements symbols, strongly typed lists, and stream oriented 
low-level i/o libraries which are based upon very simple 
requirements and pragmatic compromises. 

The implementation has been tested in the context of a large 
complex, computationally intensive application. 

The implementation is being refined on the basis of design 
reviews, code audits, time and space benchmarks, and the 
wisdom of hindsight. 


Conclusion 


The COMPASS code library is a cost-effective platform for the 
developement of new scheduling applications. 

The code library contains generic, portable, modular, and 
adaptable scheduling technology. 

It can be effectively used off-the-shelf for compatibile 
scheduling applications or it can be used as a parts library 
for the development of custom scheduling systems 

It has proved useful as a neutral benchmark for comparing the 
time, space, and qualitative performance of existing schedulers. 

It has proved useful for assessing the feasibility of building 
scheduling systems, and other symbolic applications in Ada. 
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SNC Conference on Resource Allocation - List of Attendees 
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AUTOMATING THE CONFLICT RESOLUTION PROCESS 

Jeffrey S. Wike 
TRW 

One Space Park R2-2062 
Redondo Beach, CA 90278 


INTRODUCTION 

Schedule conflicts occur when the demand for a resource exceeds the a v ajl a bnity of that 
resource. When a conflict occurs in a constraint relaxation domain, such as the p 
Network (SN) an action must be taken to resolve the conflict. Providing a erna 1 
times alternative resources, or a combination of the two, are methods of resolving a 
conflict. These alternatives are then submitted to the requestor. If no alternative is 
acceptable, the request will be declined. This process is called conflict resolution. 

The purpose of this paper is to initiate a discussion of how the conflict resolution process at 
the rework C 0ntr0 P l Center can be made more efficient. The paper will describe how 
resource conflicts are currently resolved, describe impacts of automating con ic 
resolution in the ATDRSS era, present a variety of conflict resolution strategies, an 
suggest discussion topics related to automated conflict resolution. 

CURRENT SPACE NETWORK CONFLICT RESOLUTION 

User POCCs transmit Schedule Add Requests (SARs) to the NCC by the beginning of .the 
forecast period week. The forecast period begins fourteen days prior to the week in w ic 
services are to be provided. Requests are ordered and placed on the schedule one by one 
until a conflict occurs. The request causing the conflict is placed in the declined queue. 
When all requests have either been scheduled or declined, conflict negotiation begins 
serially starting with the highest priority rejected request. Current conflict negotiation is 
a verbal time consuming process between the Forecast Analyst and the representatives of 
the user' POCCs. Because of security requirements, the user POCCs are not given access o 
the entire schedule, so they cannot identify their own time and resource alternatives^ 
Because of cucreni system limitations, the Forecast Analyst has httle automated 
information on user POCC requirements, scheduling aids, or Field of View, so it is 
difficult for the analyst to determine, other than through operational experience, which of 
the available alternatives will meet the needs of the user. 

Current NCC scheduling soRware, as with many scheduling systems, emphasizes conflict 
avoidance, rather than conflict resolution. Care is taken to place an event on the schedule 
in such a way as to avoid potential conflicts. Some of these algorithms include placing the 
event within tolerance where it will leave the largest gap of remaining unscheduled time 
or a look-ahead metric which places the event to avoid conflict with remaining 
unscheduled events. The problem with this approach is that it looks at the puzzle instea 
looking at the piece. In other words, there is no intelligence or knowledge of the 
applicability or preference of individual user conflict resolution strategies for each of the 
requests being placed on the schedule. Rather, the focus of scheduling is on the resources, 
keeping blocks of resource available time open for subsequent requests. 

Another difficulty with the current scheduling and conflict resolution process is that 
current SN service requests do not contain or xatHize flcxitnljty Plexibility ca^n e 
expressed in a request two ways. A request can include flexibility of start time by 
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specifying a plus or minus tolerance. A request can include flexibility of resource 
selection by specifying a configuration code which indicates ’open selection" for antenna 
and interface channel. Because of limitations in the scheduling message formats, the 
NCC software and the POCC scheduling software have caused users not to include time 
tolerance in their requests. Other network elements requirements have dictated that users 
specifically request certain resources instead of allowing the NCC to openly select them to 
avoid conflicts. 

In a typical schedule week, in which approximately 480 unclassified event requests were 
received by the NCC, about twenty percent of these requests resulted in schedule conflicts. 
Of that twenty percent, around sixty percent were resolved by alternate links, ten percent by 
slipping the start time, twenty percent by both slipping time and selecting an alternate 
link, and ten percent were deleted. The fact that ninety percent of the conflicts were 
resolvable indicates that there is flexibility in the user’s requirements which is not 
expressed in the request to the NCC. 

SN CONFLICT RESOLUTION IN THE ATDRSS ERA 

Because the number of service requests and ATDRSS users in the ATDRSS era (1997-2012) 
will increase three to ten fold, the number of resource conflicts will exceed the current 
ability to manually resolve them. If conflict resolution is performed one request at a time 
in priority order, the time required to resolve conflicts will be unacceptable. Automating 
the process will enable scheduling to be done in a more realistic time frame. To perform 
automated conflict resolution, information on how to resolve conflicts must be available. It 
can be identified by the user POCC in each specific service request, and/or be embedded in 
the knowledge of the NCC scheduling system. 

Embedding the Knowledge 

To perform automated conflict resolution, knowledge of user capabilities, user 
preferences, and SN resources could be embedded in the scheduling system. User 
capability data includes ATDRS to USAT and USAT to ATDRS field of view information, 
sun interference data, antenna patterns, and restrictions such as power availability that 
would limit antenna substitution. Knowledge about user preferences include mission 
characteristics affecting both flexibility in request parameters, service alternatives, and a 
weighted priority scheme for relaxing scheduling constraints. Knowledge of the SN 
includes resource availability, resource capability, RFI, to include antenna pattern 
overlap of scheduled USATs, and antenna slew time. 

Using the above knowledge, a conflict resolution profile could be created by the NCC for 
each user POCC service request defining a hierarchy of conflict resolution strategies 
applicable in each instance to the particular user spacecraft, service parameter tolerances, 
and dependencies between spacecraft services. The hierarchy would indicate the types of 
strategies to be used to resolve conflicts and the order in which they should be used. 

The knowledge about the specific user conflict resolution preferences could be input to the 
NCC scheduling system by the user POCC during service planning similar to a generic 
scheduling concept, elicited from scheduling experts at the NCC, and/or learned by the 
system during analyst-in-the-loop conflict negotiation. 

User Specifying the Knowledge 
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An alternative to embedding all the knowledge in the NCC scheduling 

the information affecting conflict resolution strategies .n the service request from the user 
POCC. The user could request a specific event (time and link) as the preferre se ™ • 
The user could also request subsequent ordered choices if the irs pre erence 1 
available. The user could prioritize request parameters. For example a specific Btarttime 
may be prefered over a specific TDRS. In addition, the user could specify in the request that 
no strategies be used (feast or famine). The information exchange necessary for both 
automated and manual conflict resolution could be facilitated by 

Space Network User Pocc Interface (SNUPI) workstation in which schedule and ^service 
flexibility could be graphically displayed and communicated simultaneously at the NCC 

and user POCC. 

Factors Affecting Conflict Resolution 

In addition to user preference, the order and precedence of conflict resolution strategies 
may be influenced by organizational and operational goals. Candidate organizational 
goals affecting conflict resolution are. 

NASA established user POCC priority. This places more emphasis on the higher 
priority users getting their first preference for conflict resolution strategies. 

Resource utilization schemes. The NCC may wish that certain users be assigned 
specific ATDRS or ATDRS links. The NCC may wish to avoid scheduling on one 
satellite, for example, the spare, except when no other conflict resolution strategy 
will work. The NCC may wish to maximize utilization of single resources, or 
ensure a leveling of resource utilization across the system. Each of these schemes 
would impact the application of conflict resolution strategies. 

Rewarding cooperation. The NCC may use priority in conflict resolution to reward 
a user POCC for following the SN rules. For example, the POCC that always has 
requests in on time, has maximum flexibility in each request, or is wi ing o give 
up a service during a conflict, may be rewarded in future scheduling by increasing 
the priority of its conflict resolution strategies. 

In an effort to achieve schedule stability, there may be operational limitations that affect 
the application of conflict resolution strategies. 

Development (forecast) period. All applicable strategies would be used on all 
requests. 

Maintenance period. Strategies that go beyond specific request tolerances for 
scheduled requests would not used, but all applicable strategies would be used for a 
request added in this period. Within twenty four hours of a service, no strategies 
would be used on previously scheduled requests. 

Spacecraft emergencies. All applicable strategies would be used to ensure the 
emergency is scheduled without conflict. 

Schedule Alternatives 

If conflict resolution is possible by performing a service in an alternative manner, 
generated through knowledge embedded in the NCC scheduling system, the alternative 
must be approved by the user POCC. For example, the user POCC may have requested an 
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SSA forward service that can be satisfied only by substituting an available SMA forward 
service. The knowledge in the system indicates that for an SSA conflict, the user satellite 
is capable of receiving the SMA forward, and the user POCC has accepted the SMA forward 
alternative in the past, but the service duration must be increased. The system checks 
Field of View data to determine if the longer duration service is applicable to the user 
satellite. The knowledge in the system may also indicate whether such a substitution is 
possible without advanced user confirmation. In either case, the alternative would be 
communicated to the user for confirmation before or after scheduling. 

Manual Conflict Resolution 

In spite of automating the conflict resolution process, special circumstances will occur in 
the ATDRSS era requiring manual conflict resolution by the SN scheduling analyst. 
Examples include when two user POCCs having the same priority (Space Station and Space 
Shuttle) have a resource conflict, when spacecraft emergencies conflict with higher 
priority user POCC schedules, or when a service bumps a lower priority user POCC less 
than twenty-four hours before the service. The analyst will have the capability to 
manually move, fix, or delete a service request from the system. Once a service conflict is 
manually resolved by the analyst, it cannot be moved as part of further automatic conflict 
resolution until the analyst removes the override. 

CONFLICT RESOLUTION STRATEGIES 

In order to resolve conflicts, there must be conflict resolution strategies. Potential 
strategies include: 

(1) Priority. The user POCC having the highest priority established by NASA for 
both spacecraft and mission, will have its service placed on the schedule ahead of a 
lower priority user service. Goodness of schedule may be determined by how many 
highest priority user services are placed on the schedule using the highest priority 
conflict resolution strategy. 

(2) Moving a service in time, by moving the request start time forward or 
backward within a tolerance window. 

(3) Moving a service to the previous or next valid view period appropriate for that 
spacecraft. 

(4) Switching to an alternate resource. If the request can be satisfied by a resource 
not specifically requested, the requested but unavailable resource may be replaced 
by the alternate, available resource. An example might be an MA forward service 
replacing an unavailable SSA forward service. 

(5) Shrinking a service duration. It may be acceptable to decrease the duration of a 
service by a few minutes in order to allow it to fit on the schedule, as an alternative 
to denying the service request. After a service has been shrunk, it may be moved 
forward or backward within tolerance. This may be particularly applicable to 
forward services which currently schedule more time than is normally used. 

(6) Breaking up a prototype event into individual services, and performing 
separate conflict resolution strategies on the individual services. Relationships 
between services, both temporal and logical, must be specified, and considered so 
that individual conflict resolution does not invalidate the entire requested event. 
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(7) Breaking up a service into multiple discontinuous services, or gapping. It may 
be acceptable to break up a requested service into two shorter services separated by a 
small, conflicting higher priority request. An example of such a service may be a 
tape playback that can be interrupted and resumed. 

(8) Combinations of the above strategies. 

(9) Deleting a service from the schedule. A higher priority request may be 
scheduled by deleting a lower priority request from the schedule, eliminating the 
conflict. 

AUTOMATED CONFLICT RESOLUTION IMPLEMENTATIONS 

Some of the automated conflict resolution concepts mentioned here are already 
implemented in existing scheduling systems. 

Plan-IT-2 developed by the Jet Propulsion Laboratory allows the scheduling analyst to 
explicitly invoke tactical plans for automatic scheduling, or read them in from a script 
file. The conflict resolution tactics specify what strategies to implement and in what 
order. 

The Experiment Scheduling Program (ESP)2, developed at Marshall Space I* light Center, 
allows users to specify weighting factors for each of the parameters in a schedule request. 
In this way, preferences can be specified for order of application, and the ' goodness’' of the 
resultant schedule can be quantified by the sum of the weights. 

DISCUSSION TOPICS 

The following issues relevant to this paper should be discussed during the working 
session: 

What specific conflict resolution strategies are applicable to the user POCCs? 

How much would conflict resolution strategies and preferences vary between services of a 
specific user POCC? 

How much would conflict resolution strategies and preferences vary between different 
user POCCs? 

Does a hierarchy of strategy preferences exist? 

Under what circumstances should manual conflict resolution be required? 

How amenable to automatic conflict resolution are user POCCs? 

How much and what type of tolerance could be communicated to the NCC from user POCCs? 
How much would tolerances vary between services of a specific user POCC? 
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Abstract 

Increases in the number of user spacecraft and data rates supported by NASA's 
Tracking and Data Relay Satellite System (TDRSS) in the S and Ku bands could 
result in communications conflicts due to mutual interference. More attention must 
be paid to this problem in terms of communications scheduling. A method to 
mitigate interference while minimizing unnecessary scheduling restrictions on both 
TDRSS network and user resources, based on consideration of all relevant 
communications parameters, has been developed. The steps of this method calculate 
required separation angles at TDRS and produce potential interference intervals, 
which can be used in the production of schedules free of unacceptable interference. 

The method also can be used as the basis for analysis, evaluation, and optimization 
of user schedules with respect to communications performance. This paper describes 
the proposed method and its potential application to scheduling in space 
communications. Test cases relative to planned missions, including Earth 
Observing System, Space Station Manned Base, and Space Shuttle, are discussed. 

Introduction 

Scheduling of user spacecraft communications utilizing the geosynchronous data relay 
satellites of NASA's Tracking and Data Relay Satellite System (TDRSS) (Figure 1) must 
Increasingly be concerned with the effects of mutual interference between users. While 
current techniques for interference mitigation are adequate for scheduling under light 
system loading, the concerns regarding mutual interference will become more serious with 
projected increases in loading, especially in the late 1990s and beyond (NASA Goddard Space 
Flight Center, forthcoming). 

Consideration of the effect of communications factors such as signal to interference 
ratio (S/I), BER margin degradation, and power received is beyond the scope of current 
TDRSS network scheduling systems. 

Furthermore, link margins are always constrained to the minimum acceptable value 
by the high costs associated with designing, building, and orbiting spacecraft with higher 
margins. Consequently, mutual interference would become more likely, and would tend to be 
more serious whenever it should occur. 

The ultimate objective is to schedule interference-free communications while 
minimizing constraints imposed both on user spacecraft missions and on the use of TDRSS 
resources. This objective cannot be accomplished absent the capability to analyze, evaluate, 
and optimize user schedules with respect to communications performance. 

The Communications Link Analysis and Simulation System (CLASS) developed by 
NASA Goddard Space Flight Center (GSFC) is a software tool for the prediction and 
evaluation of TDRSS/user spacecraft communications link performance. CLASS is a unique 
system designed to consider all communications channel parameters that affect link 
performance, including interference (NASA Goddard Space Flight Center, 1989, September). 

The need for a capability that considers all relevant communications parameters in the 
analysis, evaluation, and optimization of user schedules relative to mutual interference has 
led to the development of such a capability within CLASS. 
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An overview of TDRSS telecommunications is presented in the next section. The 
subsequent sections describe the proposed approach and present illustrative test cases. A 
discussion of results is then offered, along with a summary and an indication of directions 


TDRSS Telecommunications Overview 


NASA's Tracking and Data Relay Satellite System consists of a space segment and a 
ground segment as shown in Figure 1. The ground segment of TDRSS consists of a ground 
terminal at White Sands. New Mexico. The operational space segment consists of a user 
ransponder on each user spacecraft, and three in-service satellites in geostationary orbit at 
41, 171, and 174 degrees west longitude. In the future, a cluster of two TDRS's 3 degrees apart 
may be placed in operation at each of the approximate positions of 41 and 171 degrees west 
longitude. & 

TDRSS provides telecommunications in S band via single access (SA) and multiple 
access (MA) service, and in Ku band via the SA service. Forward links (signals from ground 
station via TDRS to user) operate at data rates from 0.1 Kbps to 25 Mbps, and return links 
(signals from user to ground station via TDRS) operate at data rates from 0.1 Kbps to 300 
Mbps (NASA Goddard Space Flight Center, 1988. September). 

Each TORS may support a maximum of five forward links: two S-band and two K-band 
on each of the two SA antennas and one S-band on the MA system. By design each TDRS 
may support a maximum of 24 return links: 20 on the MA antenna, two at S-band on SA 
• SS A) ; and two at K-band on SA (KSA). Future TDRS cluster operations will approximately 
double the resources available at each of the two geostationary positions at 41 and 171 
degrees west longitude. 

The information necessary to characterize the communication systems of TDRSS and 
user spacecraft, such as antenna type, coding scheme, data rate, signal level, or polarization 
as well as the channel environments, is maintained in CLASS data bases. All possible 
sources of effects on the RF signal are taken into account, including vehicle and earth 
multipath, vehicle blockage, atmospherics, and signal reflections from terrestrial surfaces. 

Interference Analysis Considerations 


,® in 0 C L all , TDRS forward links are PN spread, and since the data rates are less than or 
equal to 300 Kbps, the PN processing gain over Interference will be at least 10 dB. Therefore 
Interference on desired user forward channels can be neglected. 

The interference problem between two return links is more complicated because data 
rates on return links In general are much higher than on forward links, and because the 
links may or may not be PN spread and may or may not be cross polarized. Hence, In this 
paper, interference mitigation is concerned only with the user return channel. 

The problem of multiple simultaneous interferers is not considered in this paper. 

A Model for Communications Performance in the Presence of Mutual Interference 


The proposed approach to interference mitigation uses BER margin degradation 
formulated as a function of signal to interference level ratio (S/I), as the basic parameter for 
determination of channel communications performance for a link in the presence of 
Interference (Bhargava, 1981). BER margin degradation includes all the factors in the ground 
receiver (data rate (bandwidth) difference between the desired user and interferer, and 
implementation loss), and fully reflects channel performance when interference exists. 

Figure 2 shows the relationship between BER degradation and S/I in a representative 

CtlSC. 


Nonnegative BER margin is considered to correspond to acceptable communications 
performance when a link is degraded by interference. In general, degradation is computed by 
simulation, with S/I as an input parameter. y 
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Figure 2 Computed relationship between degradation and S/I for the case where the desired user is 
the Space Shuttle Orbiter using channel 3, 50 Mbps coded, and the interferer (assumed to be on the 
TORS SA antenna boresight) is Space Station Freedom using the 50 Mbps (l+Q) link. The desired user 
and interferer links are cross polarized with an assumed polarization rejection of the interfering 
signal of 15 dB on the TORS SA antenna boresight. 

The signal to Interference level ratio S/I In dB at TDRS Is defined as a function of the 
separation angle a between the desired user and the Interferer as seen from TDRS: 

£(a) = (Pd+ G(0))-(P(+ CHa) + R(a)) + Gp + Ap +I ^ ^ 


Pd = the worst case (maximum range) TDRS received power at unity antenna gain 
for the desired user (in dB) including the loss due to the nonperfect 
polarization match between the TDRS and desired user antennas. It is 
assumed that the desired user is on the TDRS antenna boresight and that 
the desired user's antenna is pointing toward TDRS. Pd includes 
contributions from stochastic sources such as multipath (vehicle, earth, 
and atmospheric) and RFI. 

Pi = the best case (minimum range) TDRS received power at unity antenna gain 
for the interferer (in dB). 

G = the TDRS antenna gain (in dB) as a function of the angle a. 

R = the polarization rejection of the interferer's signal at the TDRS antenna (in 
dB) as a function of angle a. R always has a negative value when rejection 
is present (interferer oppositely polarized ), and is zero otherwise. 

G P = io * ALOGIO (Desired user PN chip rate/Desired channel symbol rate) is the 
processing gain (in dB) of the PN spread signal 

A p _ io * ALOGIO (Interferer channel PN chip rate/Desired channel symbol rate) 
is the reduction factor (in dB) if the interferer is PN spread when the 
desired channel is not PN spread. 

Lfs = interferer power reduction (in dB) due to frequency separation. 


Lf s applies to cases (for example. non-TDRS user spacecraft from European or other 
space agencies) where the frequency separation between the desired user and the interferer is 
small (less than 10 MHz) but nonzero. Under the current TDRSS design, any two different 
TDRS-user transmitting frequencies are separated by at least 10 MHz: in such cases, 
degradation of a desired signal due to a single interfering signal may be neglected. 

In case neither desired user nor interferer is PN coded, the adjustment after the match 
filter at the ground terminal due to a large bandwidth (data rate) difference is included in the 
degradation calculation. 
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For QPSK modulation, S/I is calculated for all channels, and since the channel having 
the smallest S/I will suffer most from interference, the minimum S/I value is used. 

Since among the above terms only G and R are functions of a. Equation (1) leads 
immediately to the following for any given <*1 and “2, each an allowed value of a: 

y(«2) - y(ai) = -[G(a) + R(a)]gfgJ 

( 2 ) 

which expresses the fact that for a given change in a, the change in S/I equals the change in 
the negated adjusted antenna gain: A(S/l) = - A(G + R). 

The negated TDRS antenna gain pattern envelope, without polarization adjustment, is 
shown in Figure 3(a), modeled to represent the main beam, the first null, the peak of the first 
sidelobe, and a logarithmic relation for the remainder of the pattern. 



Figure 3. Negated TDRS SA antenna gain pattern envelope: (a) without polarization adjustment, and 
(b) adjusted by the polarization rejection of a cross polarized signal from an antenna having an axial 
ratio of 2.1 dB. Note that in both cases, the global minimum of the curve occurs at boresight (a = 0). 

Figure 3(b) shows an example of the negated adjusted antenna gain, -|G + R|. in which 
the gain of the TDFtS SA antenna is adjusted by the polarization rejection of an oppositely 
polarized user antenna. (A formulation of polarization rejection at, and a model of the axial 
ratio of, the TDFtS SA antenna are presented in the Appendix.) The transmitting antenna on 
the interferer (Space Station Manned Base (SSMB)) has a boresight axial ratio of 2.1 dB (a 
calculated value based on the assumption that the receiving TDRS antenna has a boresight 
axial ratio of 1 dB and polarization rejection of 15 dB). 

In general, the negated adjusted antenna gain curve, -|G + R). will have multiple relative 
minima. The global minimum value of the curve may correspond to more than one value for 

the separation angle a (interferer's angle off boresight). We let a denote the least such value 
of a. 

Of course, it is possible for a to be zero. Indeed, if the interferer has the same 
polarization as the desired user, the polarization rejection at the TDRS SA antenna is zero 
for all a, so that the negated antenna gain (Figure 3(a)) has its global minimum at boresight 
(under the normal assumption that the antenna gain envelope has its global maximum at 
boresight). Hence, tn this case, a*= 0. 

When the interferer and desired user are cross polarized, it is still possible for a* to be 
zero, depending on the exact nature of the model used to represent the polarization rejection 
R. Figure 3(b) illustrates such a possibility, for the case where the interferer is SSMB. As 
shown in the figure, the global minimum of the adjusted antenna gain -[G + R] occurs at zero 
degrees off boresight. so that a‘= 0 in this example. 

From Equation (2), S/I can be expressed as follows: 

£(q 1 = -[G(a) + R(a)] + AO) + [Q0) + R(0)] 
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that is the form of S/I. as a function of angle off boreslght. is merely that of the negated 
adjusted antenna gain, shifted vertically by a constant (the boreslght value of S/I plus the 
boreslght value of [G + R]). The graph of S/I is shown In Figure 4 for representative cases (to b 

descnted^aler ln Table^]^ (0 flnd a separation angle between the user spacecraft 

such Iha^no unacceptable Interference can occur. This Is the basis of the method proposed In 
this paper for mutual interference mitigation. 



Fiqure 4 S/1 as a function of interferer's angle off boresight: (a) for the case where desired user 

and interferer have the same polarization, and (b) for a representative case where deseed use and 
interferer are oppositely polarized, showing the effect, on the interfering signal, of TDRS antenna 
gain and polarization rejection. 


Worst S/I 

As the interferer moves off boresight. the interferer’s power Pi changes in a manner 
dictated by the negated adjusted antenna gain curve. When -(G + R| reaches a local minimum 
the interferer's power reaches a local maximum. Since the desired user remains 
boresight, Pd remains constant. Therefore, when -[G + R1 reaches its global minimum (e.g., 
a=a‘) the value of S/I will also reach its global minimum. This minimum S/I is the worst 
S/l", and so we have, by Equation (3): 


(-) 

1 / 'worst 


= 2(a*) = 


-[a«‘) + R(a’)] 


- 2 ( 0 ) 


[ao) + R(o)] 


Note that if «*= 0, 

(S-) = 2(0) 

1 I 'worst I 


Required S/I 

The required S/I is defined as the value of S/I such that the degradation of the desired 
user s™™uquas the worst case channel margin. Computer slmu aUon s used to obtaft. rfre 
required S/I for any given combination of desired user and interferer links The worst S/ 1 
may or may not be lets than the required S/I. If the worst S/I is less than the required S/I. 
then unacceptable mutual interference is possible for some possible separation angles. 
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Interference Mitigation via Separation Angle and Potential Interference Intervals 


Required separation angle 

. Sln< L e i the . deslred us er is assumed to be on the TORS antenna boresight, and since 
anrfi nna d< l creases boreslght, a sufficient variation of the lnterferer's separation 

f^ a «SJX^/?i SCr ? mi If ti T u etween the sl fi nals - reduces the interference le?el. and 
Increases the S/I level ratio. In the case where the required S/I is greater than the worst S/I 

if i nterf l rence pos f ble) lhe required S/I corresponds to certain separation 
angles which can be read directly from the graph of S/I (see Figure 4) Note that due to the 

fnTh^h r^ le ,i 0bes to lh „ e adJU , sled an,enna « al " e™”” < a " d therX muCte 

i£l aph f S/ ) th f re ma y , be m ul(iple disjoint ranges of separation angle providing at 

reouired S/n^defh^i^f UC t £ f S/I ” T !] e largest of a11 the an g ,es where S/I is equal to the 
required S/I is defined as the required separation angle. Any separation angle not less than 

this angle assures an acceptable level of interference. 

Potential interference intervals 

A potential interference interval is defined as any time interval during which the 
separation angle between the two user spacecraft is less than the required separation angle as 

nai?of , urln6 Such ‘utervals. unacceptable interference could occur if the given 

pair of links of the two spacecraft are active. The potential interference intervals therefore 
£° n m raIn , t ny lnt ^ rference mitigation scheduling process by specifying when the two 
links should not be used simultaneously for communications. How to decide which of the 

SJSf 8 Sh °HK be . s ^ h f duled during any potential interference interval is part of the 
algorithm used by the scheduler and is beyond the scope of this paper. P 

Potential interference intervals are calculated in a straightforward manner, based on 
given user orbital parameters and the required separation angle. 

A Procedure for Interference Mitigation in Scheduling 

A procedure is suggested for producing schedules free of unacceptable interference while 
minimizing restrictions on use of network and user resources. This procedure is based on a 
model for communications performance in the presence of interference, on required 
steps- 3110 " 3ng C ' and ° n P° tentlal interference intervals. It is summarized by the following 


(1) For every pair of desired and Interfering signals, determine -[G + R| as a 
function of a (the separation angle at a given TORS between the desired 
user and the interferer) where G is the TORS antenna gain envelope and R 
is the polarization rejection of the interfering signal at the TORS 
antenna. R is assumed to be zero if the desired user and interferer have 
the same polarization. 

(2) For every pair of desired and interfering signals, determine the least 
separation angle at which the function -[G + R] has its global minimum 
value. Denote this angle a*. 

(3) For every pair of desired and interfering signals, determine S/I, the 
signal to interference level ratio, as a function of a given by Equation (1) 
above. Calculate (S/I)(oc‘) = (S/I)(0) - [G + R](a) + (G + R](0). This is the 
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(4) For every pair of desired and interfering signals, determine by computer 
simulation the degradation of the desired signal that corresponds to 
S/I(a*). This is the desired signal's worst degradation . Identify all signal 
pairs where the desired signal’s worst degradation exceeds the desired 
user’s worst link margin. Mutual Interference will be unacceptable for 
these signal pairs. 

(5) For every pair of desired and interfering signals where interference is 
unacceptable as determined in step (4), determine by computer 
simulation the required S/I , i.e., the S/I for which the degradation is 
equal to the desired signal's worst link margin. 

(6) For every pair of desired and interfering signals where interference is 
unacceptable as determined in step (4), calculate the required separation 
angle (the largest separation angle between the desired user and 
interferer that provides the required S/I as determined in step (5)). 

(7) For every pair of desired and interfering signals where interference is 
unacceptable as determined in step (4), and on the basis of the separation 
angles obtained in step (6), find all potential interference intervals , that 
is, intervals during which unacceptable interference is possible. 

(8) Use the potential interference intervals from step (7) as a constraint to a 
scheduler for generating schedules free of unacceptable Interference. The 
effect of this constraint is to preclude the scheduling of any combination 
of desired/interferer links during any potential interference interval 
associated with that combination of links. 

The first four steps can be used as a screening process to isolate the cases where 
unacceptable interference could occur. Steps (5) and (6) would be applied in such cases, as an 
intermediate process prior to execution of a scheduling system. Step (7) would be performed 
prior to every run of an interference mitigation scheduling system (step (8)). 

Implementation 

Software to produce potential interference intervals has been implemented within the 
CLASS environment as an initial step toward development of a scheduling system 
(illustrated in Figure 5) that incorporates the interference mitigation methodology described 
in this paper. 

The principal components of the software are the analysis system, the required 
separation angle calculator, and the potential interference interval calculator. Each of these 
elements accesses the "interference analysis table". 

The analysis system accesses CLASS data bases containing link parameters (e.g., data 
rate, coding scheme, polarization, power), orbital elements, et cetera, in order to calculate 
required S/I, worst S/I, and worst degradation. These calculated values are stored into the 
interference analysis table for use by the required separation angle calculator. The required 
separation angle calculator also takes Input from a file containing orbit and view period 
data. 

Output from the required separation angle calculator is written into the interference 
analysis table. 

The potential interference interval calculator reads the required separation angles and 
calculates all intervals during which every pair of potentially-interfering spacecraft have a 
separation less than the required separation angle. The potential interference intervals are 
written into a file, which can then be used as input to a scheduler. 

Each line (record) in the interference analysis table consists of the following items: 

(1) Desired User ID 
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(2) Desired User Link ID 

(3) Desired User Channel 

(4) Desired User Polarization 

(5) Interferer ID 

(6) Interferer Link ID 

(7) Interferer Polarization 

(8) Interferer Antenna Boresight Axial Ratio 

(9) TDRS SA Antenna ID 

(10) Desired User Worst Case Link Margin 

(1 1) Required S/I 

(12) Worst S/I 

(13) Worst Degradation 

(14) Required Separation Angle 

IMSS Block Diagram 


Analysis System 



Calculate 
(S/I) required 
(S/1) worst 


Calculate worst degradation, 
corresponding to (S/I) worst 
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Angle Calculator 
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Scheduler 
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Interference 
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Figure 5. Block diagram of the proposed interference mitigation scheduling system (IMSS). The 
modules represented by the shaded blocks produce the potential interference intervals, and have been 
implemented in Goddard Space Flight Center's Communications Link Analysis and Simulation System 
(CLASS). 
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Application of the Approach: A Numerical Example 

The proposed Interference mitigation approach has been applied to planned 
including Space Shuttle Orbiter (SSO), Space Station Manned Base (SSMB), and Earth 

° bSC The^ relevant communications parameters for these three missions, as obtained from 
an internal GSFC memorandum (NASA/GSFC. 1989, January 30) concerning Shuttle links, 
and from RF Interface Control Documents (NASA/GSFC. 1989, October 27, NASA/GSFC. 

1990. February), are presented below. 

All the missions in this example operate at Ku band with carrier frequency equal to 

1 5°°ss Operates with Right Circular Polarization (RCP). Table 1 presents the link 
characteristics. 


Table 1. Space Shuttle Orbiter Link Characteristics 


CHANNEL 

Channel 1: Subcarrier Q 
Channel 2: Subcarrier I 
Channel 3: Baseband 


DATA RATE 
(kbps ) 

192 

2 , 000 
50,000 


EIRP 
(dBW) 
39.4 
43.6 
51 . 0 


LINK MARGIN 
(dB) 

19.0 
13.5 
1 . 5 


Channels 1 and 2 are rate 1/2 convolutional coded and channel 3 is uncoded 
SSMB operates with Left Circular Polarization (I.CP) at data rates of 300 Mbps and 50 
Mbps. Table 2 presents the link characteristics. 


Table 2. Space Station Manned Base Link Characteristics 



DATA RATE 


(Mbps ) 


150 

150 


25 

25 


EIRP 

(dBW) 

57 . 

, 1 

57 . 

. 1 

57 . 

. 1 

57 , 

. 1 


LINK MARGIN 



The parameters given above for SSMB are preliminary and subject to change 

EOS operates with RCP at data rates of 300 Mbps. Table 3 presents the link 

characteristics. 


CHANNEL 

— — ^ — 

DATA RATE 
(Mbps) 

-j. — 

EIRP 

(dBW) 

LINK MARGIN 
(dB) 

I 

150 

57 . 6 

3.6 

Q 

150 

57 . 6 

3.6 


Interference analysis results 

Table 4 presents the results of interference analysis. In Case 1, where the SSO 
(COLUMBIA) channel 3 (50 Mbps) experiences interference from the EOS 300 Mbps link l + WL 
the required S/I exceeds the worst S/I by 17.8 dB. The required separation angle to n»tig«Ue 
interference, which can be obtained directly from the appropriate S/ 1 graph (Figure 4(a), with 
a required S/I of 6.2 dB), is 0.74 degrees. There is no unacceptable interference ior bbu 

channels 1 and 2. 
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Table 4. Interference analysis table. 



Case 1 

Case 2 

Desired User 

User ID 

COLUMBIA 

COLUMBIA 

Channel 

z 

Z 

Polarization 

RHC 

RHC 

Worst Case Marqin 

1 . 5 

1.5 

Interferer 

User ID 

EOS 

SSMB 

Polarization 

RHC 

LHC 

Axial Ratio (dB) 

1.5 

2.1* 

TDRS 

SA Antenna ID 

DEFLT 

DEFLT 

S/I 

Required (dB) 

6.2** 

9.0** 

Worst (dB) 

-11.6 

4.0 

Worst Deqradatat ion (dB) 

★ ★ 

* * 

Required Separation Anqle (deq) 

0.74 

0.92 


♦NOTE: In this case, the axial ratio for the interferer's antenna 

is a calculated value based on an assumed value of 15 dB for 
the polarization rejection of the interferer's link on the 
boresight of the TDRS SA antenna. 

**NOTE: Obtained by computer simulation. 

In Case 2, In which the interferer is the SSMB 50 Mbps link (I + Q). the required S/I, 9.0 
dB, is greater than the worst S/I by 5.5 dB, and from Figure 4(b) the required separation angle 
is 0.96 degrees. There is no unacceptable interference for SSO channels 1 and 2. 

There is no unacceptable interference between the SSMB 300 Mbps link (I + Q) and the 
SSO channels 1. 2, and 3. 

Potential Interference Ititervals 

Potential interference intervals depend closely on the choice of orbits for user 
spacecraft. Figure 6 Illustrates this dependency by showing the Intervals for two choices for 
the user orbital elements. The only difference between these choices Is the value for the mean 
anomaly. For the choice illustrated in Figure 6 (a), the difference In the mean anomaly Is 0 
degrees, and for the choice illustrated in Figure 6 (b), it is 20 degrees. The total of the potential 
interference intervals goes from 100% of the in-view time (Figure 6 (a)) -approximately 813 
minutes during the 24 hour scheduling period-lo approximately 61 minutes (Figure 6 (b)). 
Thus, the potential interference intervals become shorter and less numerous as the orbital 
spacing of the users increases. Indeed, whenever the mean anomalies differ by more than 

approximately degrees, with all other factors remaining the same, unacceptable 

interference becomes impossible and potential interference intervals no longer exist. 

Application of Potential Interference Intervals In Existing Scheduling Systems 

Potential interference intervals also can be used in analyzing, evaluating and 
optimizing user schedules generated by current scheduling systems with respect to 
communications performance. The simultaneous communnicatlons contacts specified in 
any given schedule, produced by any scheduling system, can be compared with the potential 
interference intervals produced by the above procedure, in order to discover Interference 
problems. Each such problem could then be evaluated relative to actual mission needs, 
priorities, or other aspects of the scheduling process. If a schedule revision is decided upon, 
by either a manual or an automated procedure, it could also be similarly checked and 
evaluated. Further, the degree to which schedules are free of mutual interference based on the 
potential interference intervals discussed in this paper could be used as a measure by which 
to evaluate them relative to each other or relative to a standard. Given the capability to 
generate different alternative schedules, the ability to evaluate schedules then implies the 
ability to optimize schedules with respect to communications performance. However, it 
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would seem preferable to incorporate into the scheduler itself the ability to generate 
schedules directly reflecting the constraint of potential interference intervals (step (8) in the 
proposed procedure). 
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Figure 6. Potential Interference Intervals at (1) TDRS Spare, (2) TDRS West, and (3) TDRS East 
when the desired user is SSO COLUMBIA and the interferer is Space Station. A period of twenty-four 
hours is represented. Each user spacecraft orbit is approximately 90 minutes in duration, (a) The 
users have identical orbits, so that the separation angle is always zero degrees during TDRS view 
periods. Thus, potential interference occupies 100% of in-view time, (b) The users have identical 
orbits except for a 20 degree difference in their mean anomalies. In each orbit there are two times 
when they are separated by less than the required separation angle: once just after appearing above 
the horizon as seen by the TDRS, and once just before disappearing below the horizon. 


Summary 

The key proposition of this paper is that an interference mitigation scheduling system 
(i.e., a system capable of producing schedules that are free of unacceptable interference and 
that minimize unnecessary restrictions on network and user resources) must reflect 
consideration of communications performance. The concept of using BER degradation as a 
function of S/I, as presented above, is a sufficient basis for an interference mitigation 
scheduling system. 

In general, scheduling may involve any number of different user spacecraft. The scope 
of the approach presented in this paper is limited to the case of single interferers. The case of 
multiple Interferers is left for future work. 
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This paper presents a model of communications performance affected by the presence 
of mutvial interference. The model formulates communications performance in terms of S/I, 
which is considered as a function of the interferer’s angle off boresight. Required separation 
angles for Interference mitigation can be calculated based on this functional ralationship, 
and these angles then can be used to determine potential interference intervals (intervals 
during which mutual interference could occur). 

Potential interference intervals are proposed for use as a constraint by an interference 
mitigation scheduler. Used as a constraint, a potential interference interval disallows 
simultaneous communications by both of the links associated with the interval. By 
guaranteeing acceptable BER degradation for all desired user/interferer link combinations 
except during the potential interference intervals associated with those link combinations! 
the proposed procedure guarantees schedules to be free of unacceptable mutual interference. 
Potential interference Intervals also can be useful as the basis for evaluating and optimizing 
(with respect to communications performance) the user schedules produced bv anv 
scheduling system. J 

The method presented in this paper offers a feasible, general approach to mutual 
interference mitigation as a means for generating schedules free of unacceptable 
Interference. 

Future Work 


A scheduling system incorporating the approach described in this paper is being 
developed in the CLASS environment for use in mission planning and in communications 
performance optimization of user schedules. The effect of multiple interferers is to be 
considered In a later effort. 
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Appendix 


Polarization Rejection 

Polarization rejection, R, of the interfering signal at the oppositely polarized TDRS SA 
antenna is a function of the TDRS SA antenna axial ratio r » (not in dB) and the interferer 
antenna axial ratio r a (not in dB) : 


R = 10 Log 


\ + pi Pa +2 P» Pa COS ( 20 ) 

(l + p^)(l + 


dB 


where 


„ = r »±± 

pw 1 

r w - 1 


Note that r a 1 

and where 6 is the angular orientation of the electric field vector. The axial ratio is negative 
for right circular polarization (RCP) and positive for left circular polarization (LCP) . 

In the present application, 8 is assumed to be zero degrees in keeping with the 
assumption of the maximum effect of the interferer. 


Angle off boresight, degrees 



Figure A. Polarization rejection modeled as a function of angle off boresight at the TDRS SA antenna 
when the transmitting antenna is that of the Space Station Manned Base. 
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Figure A shows Ihe polarization rejection as a function of angle off boresight in the case 
of the TDRS SA antenna as the receiving antenna and the Space Station Manned Base high 
gain antenna as the transmitting antenna. The boresight axial ratios are 1.0 dB and 2. 1 dB, 
respectively. Axial ratio off boresight for the receiving antenna is modeled as described in 
the following section. Note that beyond the first null, since the axial ratio is undefined, the 
polarization rejection is also undefined. 

Antenna Axial Ratio Model 

The axial ratio of the TDRS SA antenna is modeled as a function of angle off boresight. 
Let a denote the angle off boresight at which the gain is 3 dB down from the boresight gain 
and let b denote the angle off boresight at the first null in the gain pattern. Beyond the first 
null, the axial ratio is undefined. The axial ratio in dB is then modeled as a broken straight 
line function of angle a off boresight: 

/l dB , ifO<a<a 


r(a) = ( (-2- a + b-2o. if a <a<b 
\\b-a b-a 


^undefined, if a> b 

_ | 20 Log r w for the transmitting antenna 
Note that I 20 Log r a for the receiving antenna 

This model is illustrated in Figure B using values for a and b of 0. 1 degrees and 0.274 
degrees, respectively. 



Figure B. Axial ratio modeled as a function of angle off boresight for the TDRS SA antenna. 
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Abstract 

Mission planning and scheduling of spacecraft 
operations are becoming more complex at NASA. 
Spacecraft contain increasingly powerful onboard 
computers which may be commanded to a vast number 
of modes and configurations. Automated planning and 
scheduling tools are needed to support the dramatic 
increase in capabilities, system performance, and user 
flexibilities. This paper describes a mission planning 
process; a robust, flexible planning language for 
spacecraft and payload operations; and a software 
scheduling system that generates schedules based on 
the planning language inputs. The mission planning 
process often involves many people and organizations. 
Consequently, a planning language is needed to 
facilitate communication, to provide a standard 
interface, and to represent flexible requirements. The 
software scheduling system interprets the planning 
language and uses the resource, time duration, 
constraint, and alternative plan flexibilities to resolve 
scheduling conflicts. 

1 Background 

NASA performs several types of scheduling. Each type 
requires different approaches and tools. Examples of types 
of scheduling include the following: 

• project scheduling: Tracking the progress of a 
project development team. 

• payload manifesting'. Determining the payload 
manifests for Space Shuttle missions. 

• job shop scheduling : Refurbishing four Space 
Shuttles for repeated launches. 


This work was funded by Goddard Space Flight Center 
under contract NAS 5-31500 with Computer Sciences 
Corporation 


• activity scheduling : Arranging activities to produce a 
time line of operations and procedures. 

77ie concepts, approaches, anti systems described in this 
paper apply specifically to activity scheduling, which is a 
part of the mission planning and scheduling process. 

We are concerned with the planning and scheduling of 
NASA mission operations with respect to spacecraft, night 
instruments, space and grountl communications networks, 
and NASA customers (science, application, and commercial 
users). In our applications, planning consists of deciding 
which instrument activities, spacecraft activities, and ground 
activities to perform, while scheduling consists of allocating 
resources to the activities and sequencing them onto a time 
line to produce a schedule. Planning is performed by 
mission planners and science users. Scheduling is currently 
performed manually with varying degrees of computer 
assistance but, as we show here, can become highly 
automated. We focus on the short term time frame from 
four weeks before an activity occurs to the actual real time 
support of an activity. Strategic planning and tactical 
planning involve long-term planning conducted months and 
years in advance and arc outside of our planning process 
except that their products, the mission goals, serve as inputs 
to our applications. 

Activity scheduling includes allocating resources and 
assigning limes to spacecraft and instrument activities. If 
resources are scarce, one must decide which activities cannot 
be scheduled. Temporal constraints between activities 
restrict activity scheduling (c.g., Activity A must be 
scheduled before Activity B). 

Several techniques are available for generating conflict- 
free schedules, including hybrid neural network/henristic 
approaches as described in [Gaspin, 1989), heuristic 
approaches as described in [Berner, 1989), and, if the 
problem is sufficiently constrained, mathematical 
programming approaches (linear and nonlinear) as in [Reddy, 
1989). Techniques for improving an existing schedule 
include a neural network approach as described in [Sponsler 
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and Johnston, 1990] and a best- first search approach as 
described in [Odubiyi and Zoch, 1989]. 

As flexibilities arc added to plans, the scheduling 
procedure becomes more complex. For instance, if specific 
resource requirements, start times, and end times for an 
activity are requested, a scheduling system can respond with 
a yes or no. If flexible resource requirements and general 
temporal requirements are specified instead of specific 
requirements, the scheduling software must search the 
current schedule for places where temporal requirements and 
resource requirements are met. If nominal resource 
requirements cannot be met, the scheduling system can 
utilize the specified resource flexibilities and try again to 
schedule the activity. For example, instead of specifying a 
request for a 10-minute communication with TDRS-E 
(Tracking and Data Relay Satellite, East) at 3 p.m. on a 
certain day, a plan might specify that communication with 
either TDRS (East or West) is needed between 2 p.m. and 4 
p.m. 

The Data Systems Technology Division (Code 520) at 
Goddard Space Flight Center has developed a testbed to 
investigate the scheduling process for increasingly complex 
future NASA missions. The testbed includes a mission 
planning and scheduling system called the Request-Oriented 
Scheduling Engine (ROSE), that addresses the activity 
scheduling problem. Spacecraft operation plans are input to 
ROSE in a robust planning language called the Flexible 
Envelope Request Notation (FERN). 

In this paper we describe (1) the need for increased 
automation in mission planning and scheduling, (2) the 
mission planning and scheduling process, (3) the FERN, and 
(4) the ROSE. 

2 The Need for Automation 

Several factors motivate the need for increased automation. 
These factors include the complexity of flight instruments 
and spacecraft, the need to provide increased flexibility to 
users, the need for safely, and the support for complex, 
distributed scheduling architectures. Each factor is discussed 
below. 

2.1 Complexity of Flight Systems 

NASA flight instruments and spacecraft arc physically larger 
and more complex than past space systems. Past space 
systems were relatively simple since there was no way to 
repair onboard hardware failures. Now, the Space Shuttle 
crew can repair and service low-earth orbiting spacecraft. 
Thus, a major obstacle that restrained complexity has been 
removed for many missions. 

Increasingly powerful onboard computers have greatly 
expanded the capabilities of flight systems which may be 
commanded to a vast number of modes and configurations. 
Automated scheduling systems on the ground arc needed to 
support the automated flight systems and keep track of 
operation lime lines which contain numerous constraint and 


activity relationships. Manual scheduling is becoming 
impractical. 

2.2 The Need for Flexibility 

Presently, instrument and spacecraft activities are conducted 
according to an operations time line developed ahead of Lime. 
Users want a more flexible approach that allows real-time 
user interactions with instruments. They want the 
capability to select and perform different activities based on 
the results of real-time telemetry without going through a 
lengthy rescheduling process. Scientists often wish to re- 
plan operations to react to a "target of opportunity" (an 
interesting phenomenon such as a significant sun flare, 
volcano, or hurricane). Rapid, safe rescheduling may be 
carried out more quickly using automated systems instead of 
manual methods. 

2.3 The Need for Safety 

Evaluating the impact of schedule changes is difficult. 
Automated scheduling systems provide increased flexibility 
to manage schedule changes while ensuring health and safety 
of space systems. Automated systems perform constraint 
checking and produce various reports such as impact 
evaluation, schedule statistics, and history logs in order to 
minimize problems introduced by schedule changes. 

2.4 Distributed Scheduling Hierarchy 

Automated scheduling systems arc needed to support remote 
science users. Instead of depending on a centralized 
operations control center to operate their instruments, 
science users may directly control the flight instruments 
from a university or other home institution. The planning 
and scheduling capability is no longer centralized in one 
place; instead, the planning and scheduling capability is 
distributed between the operations control center and the user 
sites. Figure 1 and Figure 2 show examples of distributed 
planning and scheduling architectures. 

The system architecture is hierarchical because the 
operations control center must schedule space-to-ground 
communications support with the Network Control Center 
(NCC). Planning and scheduling systems exist at the NCC, 
the operations control center, and the customer sites. With 
such a complex architecture, automated scheduling becomes 
mandatory. 

Figure 1 illustrates the planning and scheduling 
hierarchy that currently exists. The network level (level 1) 
contains the NCC and the Flight Dynamics Facility (FDF). 
The NCC is the control center that schedules 
communication services for spacecraft that use the Tracking 
and Data Relay Satellite System (TDRSS). The FDF 
provides orbit, attitude, and navigation products used for 
generating mission plans and schedules. At the platform 
level (level 2), spacecraft are controlled and managed by 
Payload Operations Control Centers (POCC) or Mission 
Operations Control Centers (MOCC). Presently, at the 
payload level (level 3), the Space Shuttle may contain 
Spacclab payloads managed by the Spacelab POCC. 
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Figure 1. Current Planning and Scheduling Hierarchy 
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Figure 2. Freedom Era Planning and Scheduling Hierarchy 
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The Space Station Freedom environment is an example 
of a complex, distributed, hierarchical planning and 
scheduling network. For the Freedom era, the planning and 
scheduling process will be more automated and distributed in 
a hierarchy containing additional levels and elements at each 
level. 

Figure 2 illustrates the planning and scheduling 
hierarchy for the Freedom era. With additional levels and 
elements, the Freedom era hierarchy is more complex than 
the current hierarchy. The network level (level 1) is similar 
to the current configuration. The platform level (level 2) 
includes the Earth Observing System Operations Center 
(EOC), the Space Station Control Center (SSCC), and 
POCCs for various spacecraft At the payload level (level 
3), the Payload Operations Integration Center (POIC) at 
Marshall Space Flight Center (MSFC) coordinates activities 
among the international partners [i.e., Japan and the 
European Space Agency (ESA)] and many Instrument 
Control Centers (ICC) for use of the manned base resources. 
The customer level (level 4) includes the principal 
investigators and the ICCs for the instruments. The ICCs 
may support guest investigators and co-investigators who 
use remote user workstations or Instrument Support 
Terminals (1ST) (level 5) to communicate with an ICC. 

3 The Mission Planning Process 

Figure 3 shows a mission planning process. Strategic 
mission goals are developed at the beginning of a mission. 
During routine operations, a repetitive planning process 
occurs, typically on a weekly cycle. Investigators and 
coinvestigators generate plans for instrument operations. 
Specific resource availability profiles may not be known due 
to security rules or the commercial proprietary nature of 
certain payloads. 

While investigators arc generating instrument plans, 
spacecraft operations personnel are generating plans for 
maintaining the health and safety of the satellite. These 
plans include operations such as tape recorder dumps, 
command loads, and orbit adjustments. 

Typically a week or two prior to schedule execution, 
plans from the investigators are integrated with spacecraft 
operations plans, and then schedules are produced. Schedules 
arc analyzed by scheduling personnel to verify that mission 
goals arc being met. If the schedule docs not adequately meet 
the mission goals, it can potentially be improved by using 
the flexibilities specified in the plans (relaxing resource 
requirements or scheduling alternative activities, for 
example). In distributed environments, scheduling personnel 
may request additional resources from other scheduling sites. 
After the schedules are produced, they arc sent to the 
investigators. If schedules are not satisfactory, investigators 
may submit altered plans. 

4 The FERN Language 

In an automated scheduling system, users need to express 
plans for operations in a format that computers can interpret. 


In general, defining requirements is not simple, whether the 
requirements describe software functionality, hardware 
capability, or as in our application, user instrument 
operations plans and resource requirements that support 
science experiments and flight operations. User resource 
requirements may be complex because user activities are 
diverse, flexible, and changeable. Their activities may be 
related to constraints, orbital events, and other activities. A 
better mechanism is needed to represent this information. 


Mission Goals 



Figure 3. The Mission Planning Process 


Since people use languages to communicate, we 
propose that user plans be represented in a language formal 
that computers can process. A language format is needed to 
express the flexibilities and alternatives contained in the 
instrument plans. This method is more expressive than 
using data structures such as arrays, records, and tables. We 
use a language format called FERN (Flexible Envelope 
Request Notation). 

FERN has proven to be a general scheduling language. 
It has been used to represent Solar Mesosphere Explorer 
(SME) requests. Upper Atmosphere Research Satellite 
(UARS) requests, and NCC requests. 

In many scheduling environments currently in 
operation, conflicts are often resolved manually. Sometimes 
users meet to resolve conflicts; however, with increased 
security restrictions due to DOD and commercial payloads, 
this form of conflict resolution might no longer be 
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permitted. FERN provides the flexibility that allows an 
automated scheduling system and project operations 
personnel to resolve conflicts without violating security 
restrictions and rules. 

FERN supports expressing scheduling requirements at 
different levels of abstraction. Detailed resource 
requirements are specified at the lowest level in steps. 
Resource usage within a given step is constant over the 
duration of the step while the duration is often variable. 
Steps can be grouped together into activities. In an 
operational environment, steps would be defined at the 
beginning of a mission and then grouped into meaningful 
activities. Future planning would be done using mnemonic 
activity names without the need to recalculate detailed step 
requirements. A pattern of repetition for activities can be 
specified in a generic request. A generic request can 
succinctly represent a plan for recurring operations. Each 
generic request is assigned a priority by the user, which 
indicates its importance relative to other requests by the 
same user. Temporal constraints can be specified between 
steps or between activities. Figure 4 shows the organization 
of information within generic requests, activities, and steps. 





Constraints 


Figure 4. Information Contained in Steps, 
Activities, and Generic Requests 


The following sections describe in more detail some of 
the specific features of FERN. For each requirement in an 
activity (a resource requirement or a temporal constraint), the 
user may specify a relaxation level ranking from 1 to 10. If 
a schedule is generated that is not consistent with mission 
goals, scheduling personnel may successively relax 
requirements as specified to attempt to improve the schedule. 
Requirements with a ranking of 1 are relaxed first. If no 


relaxation level is specified, the requirement cannot be 
relaxed. 

4.1 Resource Flexibilities 

FERN allows resource amounts to be specified at different 
relaxation levels. For example, a power requirement can be 
specified with two relaxation levels as follows: 

POWER (300 watts 

AND 250 watts AT RELAXATION 2 
AND 150 watts AT RELAXATION 6) 

In this example, if 300 watts of power is not available, the 
scheduling system tries to schedule the request at 250 watts 
and then 150 watts. Requirements with relaxation levels 3, 
4, and 5 are relaxed before the power requirement is relaxed 
from 250 watts to 150 watts. 

With no specified relaxation, the example becomes: 

POWER 300 watts. 

4.2 Temporal Expressions 

We use the term "interval" to represent a window in time 
with a specific start and end time and the term "interval set" 
to represent a collection of nonoverlapping intervals. 
Temporal expressions allow users to create new interval sets 
as functions of predefined interval sets and give names to 
them such as "weekday" and "spacecraft night.” Users may 
define new interval sets by applying the UNION, 
INTERSECT, MODIFY, and SELECT operators to existing 
interval sets. 

The UNION and INTERSECT operations are set 
operators. For example, given a temporal interval such as 
"Wednesday" representing a particular 24-hour period and an 
interval set such as "afternoon", which contains the time 
period from 1 p.m. to 4 p.m. every afternoon during a week, 
an interval representing "Wednesday afternoon" could be 
defined by intersecting "Wednesday" and "afternoon". 

The MODIFY operation is useful for changing the start 
and end times of an existing interval. For example, to create 
an interval that lasts from 2 p.m. to 3 p.m. using the pre- 
defined interval above, specify: 

MODIFY Wednesday-aftemoon 

WITH START LATER by 1 hour 
WITH END EARLIER by 1 hour 

The SELECT operator allows specific windows 
(intervals) within an interval set to be "selected". For 
example, to "select" the second and fourth afternoons from 
the "afternoon" interval set, specify the following: 

SELECT afternoon (2, 4) 

Temporal expressions are an important tool that enables 
users to work with their own terminology. 
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4.3 Temporal Constraints 

Once a temporal interval such as "Wednesday -afternoon" is 
defined it can be used within a temporal constraint. For 
instance: 

activity x DURING wednesday-aftemoon. 

FERN contains a general temporal constraint facility for 
expressing indefinite interval relations and the thirteen 
simple interval relations as described in [Vilian and Kautz, 
1986J. Temporal relationships can be specified between two 
activities or steps. One form of a constraint construct is: 

Request x 
[STARTS I ENDS] 

[MORE THAN I LESS THAN I EXACTLY] 

<duration> 

[BEFORE I AFTER] 

[<activity>l <step>]. 

For example. 

Request X starts more than 5 minutes 
before Request Y. 

Simple interval relations such as "before" and "after" are 
expressed in a similiar English-like syntax. 

4.4 Alternative Activities 

Alternative requests allow users to request an entirely 
different activity if the resource scheduling algorithm cannot 
accommodate the initial request. Users want to propose 
alternative experiments if their initial plans cannot be 
supported. 

4.5 A Generic Request Example 

To illustrate the hierarchy of the generic request capability, a 
sample set of FERN definitions is shown below. Upper 
Atmospheric Research Satellite (UARS) contains 10 
scientific instruments. One of these instruments is the 
Improved Stratospheric and Mesospheric Sounder (ISAMS) 
which has a 100 percent duty cycle viewing the Earth's 
atmosphere limb. There are separate instrument modes for 
spacecraft day and night. This example only uses some of 
the expressive capabilities of the language, but it shows the 
ability of generic requests to generate many schedule 
activities over an indefinite period of time: 

Generic ISAMS_NORMAL_GEN is 
1 ACTIVITY PER UARS„Orbil 
SCHEDULE 
ISAMS_Normal_Act 
END GENERIC 

This example of a generic request definition is 
straightforward. One occurrence of the activity 
ISAMS_Normal_Act is to be scheduled every UARS orbit. 
The activity may turn out to be simple or complex. The 
activity definition is shown below. 


ACTIVITY ISAMS_Normal_Act is 
STEP 

ISAMS_Daytime_View_Step 

FOR AS LONG AS POSSIBLE, 

ISAMS_Nighttime_View_Step 

FOR AS LONG AS POSSIBLE 
END ACTIVITY 

This example shows that the activity is made of two 
parts (steps). The first step occurs when the spacecraft is in 
daylight, and the second step occurs during spacecraft night. 
The activity definition includes the step durations. A 
duration of "for as long as possible" needs a constraining 
time interval. In this case, the constraint is indicated in the 
step definition: 

STEP ISAMS_Daytime_View_Step is 
RESOURCES 

ISAMS, 

UARS_Power 14 waus 
CONSTRAINT 

Occurs Entirely During UARS_Daytimc 
END STEP 


STEP ISAMS_Nighttime_Vicw_Step is 
RESOURCES 

ISAMS, 

UARS_Powcr 14 watts 
CONSTRAINT 

Occurs Entirely During UARS_Nighttime 

END STEP 

Steps contain the resource allocations that support the 
activity. In addition, steps may have constraints that restrict 
time periods when they can be scheduled. The 
ISAMS_Daytimc_View_Step can only occur during the 
time period defined as U ARS_Daytime. 
ISAMS_Nighttime_View_Step can only occur during 
UARS_Nightlime. These constraints restrict the actual 
starting and ending limes for the steps. If other requested 
resources such as UARS_Power are available during the 
appropriate time periods, the steps are scheduled for the 
entire duration of the time period UARS_Daytime and/or 
UARS_Nighttime. 

Note that some additional definitions must exist in order 
to process the above FERN requests. Resource availabilities 
for ISAMS and UARS_Power must be defined. Time 
periods for UARS_Orbit, UARS_Daytime, and 
UARS_Nighttime must also be defined. Since the ISAMS 
often performs the same science information gathering 
experiments, these requests can be used repeatedly as needed. 

5 The Request-Oriented Scheduling 
Engine (ROSE) 

ROSE is currently under development as a scheduling tool 
to demonstrate automated scheduling and distributed 
scheduling concepts. The current major capabilities of 
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ROSE are as follows: (1) to receive scheduling messages 
via a file transfer protocol from any scheduler or user located 
on the host network and respond with appropriate scheduling 
messages, (2) to create an initial schedule from user requests, 
and (3) to reschedule (as needed) to satisfy mission goals. 

ROSE was originally implemented on a Texas Instruments 
Explorer and has been ported to the Symbolics 36xx 
environment under Symbolics OS Release 6.1 and Genera 7. 
The system is currently being ported to Ada in a VMS 5.1 
environment using X-windows. Since we anticipate a port 
to a UNIX Sun/3 environment we are avoiding using any 
features that would make this port difficult, such as VMS 
system services, implementation-dependent language 
features, and implementation-dependent X tool kits. 

5.1 Communications Capabilities 

ROSE supports interscheduler communication through the 
transmission of resource requests and schedules. Users 
transmit requests expressed in the FERN language to ROSE. 
The user receives two responses from ROSE. The first is an 
acknowledgement message that confirms receipt of the 
message. This message indicates whether errors were 
delected by the FERN parser. When all requests are received, 
a schedule is created. The second response ROSE sends is 
schedule messages indicating the name of scheduled requests, 
the time assigned to the request, and the resource levels 
dedicated to the request. Users receive a schedule message 
for each request sent to ROSE, but are not informed of the 
disposition of requests from other users. 

5.2 Scheduling Capabilities 

The ROSE system creates an initial schedule from a set of 
requests, resources, and interactively-specified scheduling 
heuristics. ROSE currently schedules activities at the rate of 
approximately 900 activities per hour on a 1 MIP VAX 
workstation for schedules with 1000 - 2000 requests. The 
ROSE operator chooses a selection heuristic and a placement 
heuristic from predefined menus. The selection heuristic 
evaluates each activity and determines which activity should 
be scheduled next based on priorities, resource consumption, 
and an estimation of the restrictiveness of an activity's 
temporal constraints. The placement heuristic uses activity 
preferences and information about the existing schedule to 
determine the placement of the activity. The ROSE operator 
can create many different alternative schedules by selecting 
different combinations of selection and placement heuristics. 
Alternative schedules can be compared and evaluated with 
respect to mission goals. ROSE always creates conflict-free 
schedules. Manual scheduling is also supported through the 
graphical interface. 

5.3 Rescheduling Capabilities 

In a resource constrained environment, resource conflicts 
will occur, and rescheduling will usually be a necessary step 
after the initial schedule is created. A simple approach for 
scheduling is to resolve resource conflicts by choosing the 
higher priority activity. In a network of ROSE schedulers, 
each allowing flexible requests, there are several options: 


• Overbook the resource. In our distributed scheduling 
environment, overbooking is a viable conflict resolution 
scheme since additional resources can potentially be acquired 
from another scheduler. 

• Relax this activity. A minor adjustment to the 
scheduling requirements of the request might make it 
possible to schedule it 

• Relax other activities. Higher priority activities 
might have their requirements relaxed in order to 
accommodate lower priority activities. 

- Acquire additional resources. In a network of 
schedulers, it might be desirable to request and obtain 
resources from another scheduler. 

• Manually add the activity . ROSE provides operator 
displays and tools that support the interactive rescheduling 
of existing activities. 

• Use the automated Schedule Enhancement Technique. 
ROSE provides an automated heuristic search capability 
similar to a best-first search. This technique has proven 
useful in enhancing existing schedules. The search proceeds 
by looking for times on the schedule when an activity can 
almost be scheduled. The algorithm then finds those 
activities that need to be deleted to make it possible to 
schedule the activity, and then reschedules the deleted 
activities. This technique is described in more detail in 
[Odubiyi and Zoch, 1989]. 

• Choose the higher priority activity . As a last resort, 
some activities are not scheduled. 

• Use any combination of the above capabilities -- An 
operator can mix and combine these techniques as needed to 
improve the current schedule. 

An operator may reschedule activities to improve a 
schedule, to cope with equipment failures, or to 
accommodate changes in plans. The operator is faced with 
an overwhelming amount of information. An interactive 
interface must effectively organize, filter, and display this 
information at the appropriate level of detail to aid an 
operator in making informed scheduling decisions. ROSE 
aids an operator in analyzing and comparing existing 
schedules and in making modifications to improve a 
schedule, respond to changes in resource profiles (equipment 
failures), or respond to new user requests. These features 
have proven to be a valuable aid in assessing the situation 
and modifying existing schedules. 

5.4 ROSE User Interface 

Figure 5 shows the ROSE interface. The three main 
windows are the Distributed Scheduling Network Window, 
the Real-Time Message Monitoring Window, and the 
Timeline of Scheduled Requests Window. 
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Figure 5. ROSE Interface with Sample Schedule and Resource Plots 


The Distributed Scheduling Network Window displays 
the scheduling network and the message traffic within the 
network. Each rectangle represents either a NASA 
scheduling facility such as a Payload Operations Control 
Center (POCC) or a user Instrument Control Center (ICC). 
Figure 5 shows a simplified scheduling network for Space 
Station Freedom. The Platform Management System 
(PMS) makes block allocations of resources to scheduling 
centers P01 and P02. Scheduling requests are sent from the 
Instrument Control Centers (101, 102 and 103) to scheduling 
facilities P01 and P02 where schedules are created. Users at 
101, 102 and 103 are then sent scheduling messages that tell 
them where their requests were scheduled and the amount of 
resources that were allocated. 

The middle portion of the screen is the Real-Time 
Message Monitoring Window. This window displays the 
names of scheduling messages received by this scheduler 
from other schedulers in the network. The user can click on 
these message names to view the details of these messages. 

The lower portion of the screen displays the Timeline of 
Scheduled Requests Window. Schedules arc currently one 


week in duration. Each time line shows the requests 
scheduled for a particular user instrument. Multiple 
schedules may be created using different scheduling 
heuristics. Once created, an operator can rearrange these 
time lines so that the different schedules can be compared. 
The operator can also perform standard window 
manipulations such as panning and zooming on any part of 
the time line. The Timeline of Scheduled Requests 
Window, in conjunction with the Unscheduled Request 
Window, provides an object-oriented graphics interface to all 
requests. Every request can be viewed, edited, relaxed, 
scheduled, or unscheduled. 

The Timeline of Scheduled Requests Window is also 
used to display resource plots. Resource profiles can be 
obtained for original resource amounts, remaining resource 
amounts, and resource amounts used by a particular ICC. 

During the scheduling process, a ROSE user can set an 
overbooking limit for each resource. This option is useful 
for investigating the effects of having additional resources. 
The scheduler will treat these extra amounts of resources as 
if they were actually present. As shown in Figure 5, ROSE 
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can display a time line showing where over booked amounts 
are actually utilized. Clicking the mouse on a rectangle on 
this time line generates a display showing which resources 
are overbooked at that time. 

Figure 6 shows the ROSE interface displaying the 
results of a draw available start times operation. This 
display gives the operator a complete understanding of why a 
request could not be scheduled. A time line is displayed for 
each resource requirement or temporal constraint in the 
request. The dark areas on the time line show where the 
particular requirement is satisfied. The top time line, 
labeled INTERSECTION, displays the intersection of all the 
other time lines. It shows the places where the request can 
be scheduled. As shown in Figure 6, the draw available start 
times display contains a time line for the following: 

• Every resource or environmental constraint used by 
the request (POWER, COM-LINK, TAPE-RECORDER, 
VIBRATION, and N02-SPEC). The dark areas show places 
on the time line where sufficient resources arc available to 
meet the needs of this request. 


• Each temporal constraint (labeled 1 and 2). The dark 
areas show places where the temporal constraint is satisfied. 

• The DIRECTION constraint (labeled DIRECT). This 
is a special type of temporal constraint. 

Two summary time lines arc also shown, labeled 
DYNAMIC and TEMPORAL. The DYNAMIC time line 
shows where a request can be scheduled based on its required 
positioning with respect to other requests. The 
TEMPORAL time line displays the intersection of all 
temporal constraints and the special DIRECTION constraint 
for the request. 

The draw available start times display identifies the 
schedule conflict areas. For example, the N-PROBH-3 
request has a DIRECTION constraint that is restricting the 
scheduling of this request to a short period early in the 
schedule. The N02-spcctrometcr instrument is busy during 
the early part of the week, making it impossible to schedule 
the request. Other resources such as POWER and TAPE- 
RECORDERS arc abundant. 
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Figure 6. ROSE Interface with Display of Available Start Times for Request N-RROBH-3 
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6 Conclusion 

Wc have addressed a difficult aspect of mission planning and 
scheduling-representing the available flexibilities in plans 
to aid in the automation of the scheduling process and reduce 
replanning. The increased automation is necessary to 
support increasingly complex future NASA missions. 

The FERN planning language is designed to be robust, 
readable, flexible, and object-oriented. FERN supports a 
variety of user resource requirements and constraints. It 
supports alternative plans and repetitive activities that are 
based on temporal expressions (user-defined time periods) 
rather than specific start times. The language contains 
hierarchical constructs that support data abstraction and 
reusable data objects. 
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Abstract - The limited availability and high cost of crew time and scarce resources makeopUmization of space operations critical. 
Advances in computer technology coupled with new iterative search techniques permit die near opt.mizauon of comp ex 
scheduling problems that were previously considered computationally intractable. This paper describes a class of search 
techniques called Intelligent Perturbation Algorithms. Several scheduling systems which use these algorithms to opUmize the 
scheduling of space crew, payload and resource operations are also discussed. 


Using Heuristics for Optimization 

The development of techniques to solve scheduling 
problems has historically centered around the investigation 
of idealized scheduling models which were often simpler 
than problems typically encountered in the real world. 
Except for the simplest models, scheduling problems can be 
described mathematically as “NP-Hard.” 3, 14 All known 
mathematical techniques for finding optimal solutions to 
NP-Hard problems are too slow to solve realistically large 
problems . 15 

In practical applications, heuristic techniques arc 
often used to solve problems which are otherwise intractable. 
Heuristics usually produce solutions of good quality but do 
not always find the most optimal solution. Whereas the 
computational difficulty of finding the exact optimum solu- 
tion increases exponentially as a function of the size of an 
NP-Hard scheduling problem, with heuristic algorithms the 
difficultly of finding “quasi-optimaT solutions usually in- 
creases only in a polynomial fashion. Polynomial heuristic 
algorithms can therefore find solutions to realistic problems 
in a computationally feasible search time. 

In some cases, heuristic techniques can be shown to 
produce solutions which have desirable properties such as 
guaranteeing to always be within a certain percent of the 
optimal solution. For more complicated problems, however, 
even these guarantees may not be possible. In the case of 
many space related scheduling problems, the optimization 
criteria can be inexact and the data base (e.g., estimates of the 
expected time necessary to complete an activity) may be 
uncertain; hence, a heuristic can be considered successful if 
it can be applied to a set of test problems and shown to 
consistently produce schedules which are nearly optimal. 
With confidence in such a heuristic it could then be applied 
to larger and more complicated problems for which finding 
the optimum is not realistic. Additionally , having a heuristic 
which can compute a solution on a time scale fast enough for 
the solution to be used immediately (as would be necessary 
to perform real-time replanning) is superior to producing a 
nominally better solution which cannot be obtained in real 
time. 


Intelligent Perturbation Algorithms 

A typical scheduling problem involves the placing 
of activities onto a timeline while respecting constraints 
which may restrict the times at which the activities many be 
performed and the resources available for the activities to 
use. A grading function is established to judge the relative 
merits of different schedules. 

Intelligent Perturbation Algorithms arc heuristic 
techniques that have been developed by the author for the 
quasi -optimization of complex scheduling problems. These 
algorithms iteratively search the combinatoric solution space 
just as techniques such as gradient search are used for solving 
continuous domain optimization problems. Like other itera- 
tive search techniques such as Simulated Annealing Algo- 
rithms 1 * 3 * 7 * 16 and Genetic Algorithms 1718 , Intelligent Pertur- 
bation Algorithms iteratively examine (and make perturba- 
tions upon) successive schedules in an attempt to find a 
progressively better solution. Unlike these other techniques 
(which search in a more random fashion), Intelligent Pertur- 
bation Algorithms use a strategy that considers both the 
structure of the problem’s constraints and its objective func- 
tion to decide how to modify a schedule to increase the like- 
lihood that the next perturbation will yield a more optimal 
solution. 

To create an initial schedule (the first iteration), a 
method is devised to generate a ranking of all unscheduled 
activities, and then the highest ranked activity is added to the 
timeline. The procedure is then repeated to select the activity 
with the next highest ranking, adding it to the timeline. This 
continues until all the activities (or as many as possible) have 
been added to the schedule. The particular method used to 
initially rank the activities and the specific way in which 
activities are added to the timeline are not pertinent to the 
general operation of the Intelligent Perturbation Algorithm. 

Following this first iteration, the rankings of the 
activities are adjusted using a problem specific procedure 
called a perturbation operator. These new rankings are then 
used on the next iteration to produce another schedule which 
is hopefully of superior quality (as measured by the grading 
function). This process then repeats for subsequent iterations 
until a cutoff criteria is reached. The best schedule found 
during the course of the search is then recalled. 
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Empcrical experience has shown that good pertur- 
bation operators share many characteristics: 

1) The operator should increase the rankings of an 
activity or activities which were not satisfactorily 
scheduled during the previous iteration. The opera- 
tor should also increase the rankings of “bottle- 
neck” activities (which may have been successfully 
scheduled) that prohibited the satisfactory schedul- 
ing of other activities due to temporal constraints 
linking those activities to the bottleneck activity. 

2) The operator should be able to potentially span the 
search space in a small number of steps. 

3) The computational overhead of computing the 
perturbations between each iteration should be 
small compared to the computational cost of pro- 
ducing a single schedule. Extensive testing has 
shown that by looking at many good schedules, 
Intelligent Perturbation Algorithms arc likely to 
find a very good schedule in a reasonable number of 
iterations. There is a greater payoff in searching 
through more schedules than in investing a great 
deal of computation in the perturbation operator. 
This is consistent which the strategy employed by 
the best chess playing computer programs which 
achieve their skill by searching through a large 
number of positions rather than through the use of 
strategy. 

4) The perturbation operator should have a random 
component (or some other provisions) for avoiding 
loops and getting trapped near local optima. 

For many space operations, the costs of opportuni- 
ties which are lost due to inefficient scheduling can easily 
amount to millions of dollars per week. The proper design of 
the perturbation operator is critical to the success of Lhc Intel- 
ligent Perturbation Algorithm, and will vary for different 
types of scheduling problems. The specific details can be 
considered proprietary; as the utilization of space becomes 
more commercial, the possession of good perturbation op- 
erators can provide a capability to operate more efficiently 
and thereby bestow a competitive advantage. 

Intelligent Perturbation Algorithms can be made 
flexible enough to accommodate a large range of problem 
structures including highly 
complicated constraint envi- 
ronments which could not be 
addressed by previous heu- 
ristic optimization methods. 

The search inherently fo- 
cuses on the complicated 
parts of a scheduling prob- 
lem while it avoids dealing 
with factors which are not 
present in a particular prob- 
lem instance. 

Figure 1 shows re- 
sults of using the Intelligent 
Perturbation Algorithm, av- 
eraged over many test prob- 
lems. 10 In each problem, the 
objective was to generate a 


timeline which allowed complcuon of a set of tunc and 
resource-constrained activities as early as possible. Using 
non-itcraLive heuristic techniques standard in operations 
research literature, solutions were found which averaged 
about 23% longer than optimal; after 1 0 search steps using an 
Intelligent Perturbation Algorithm, average schedule quality 
was improved to within 10% of the optimum, a significant 
improvement. After 100 search steps, Lhe average schedule 
quality was improved to only 7% longer than the optimum. 
Usage on many different problems has shown that while the 
scaling of the axes will vary for different types of scheduling 
problems, the general character of the “learning curve” 
relating schedule quality to the number of iterations remains 
largely unchanged. 



Figure 1: Solution Improvement with Iteration Number 

Intelligent Perturbation Algorithm Applications 

Aerospace systems have been developed which 
apply Intelligent Perturbation techniques to Lhc scheduling of 
crew, payloads, and resources aboard space-based systems. 
Space Industries is examining the application of Intelligent 
Perturbation Algorithms beyond the aerospace industry into 
diverse areas such as the optimization of petrochemical plant 
operations and the scheduling of medical operating rooms. 
Additionally, an independently developed iterative refine- 
ment methodology, called chronology-directed search, has 
been developed at JPL and is being applied to the scheduling 
of deep space missions. 2 

Space Station Scheduling 

Aboard the International Space Station Freedom , 
crewmembers would benefit from having the capability to 
participate in the scheduling of their own activities. To 
address this need a prototype 
interactive software tool 
known as the MFIVE Space 
Station Crew Activity Sched- 
uler and Stowage Logistics 
Clerk was developed at the 
Space Systems Laboratory of 
the Massachusetts Institute of 
Technology (MIT). l0> '*• 12 
MFIVE (Figure 2) provides a 
user friendly interface for 
building, solving and display- 
ing scheduling problems as 
well as for investigating the 
features which will be neces- 
sary to provide a real-time 
scheduler for use aboard 
Freedom. 


Mf IUE Stop Options Rutoplan Constraints Mouse Mode 



Figure 2: MFIVE Space Station Scheduling Worksheet Showing 
Task Assignment and Resource Usage for Five Crewmembers 
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MFIVE was not intended to provide a fully robust 
model of the realistic Space Station environment but rather to 
demonstrate some of the features which will be necessary to 
support development of actual Space Station planning and 
scheduling tools. While Ihe MFIVE system was created to 
deal primarily with manned activities, it is also capable of 
dealing with unmanned operations. First prototyped in 1 986, 
MFIVE was used to develop and test the initial implementa- 
tions of the Intelligent Perturbation Algorithm. MFIVE also 
demonstrated user-friendly features such as graphics, win 
dows, menus and a mouse-driven interface on a low cost 
Macintosh desktop computer. 

MFIVE is currently being used by the MIT Man 
Vehicle Laboratory to examine scheduling scenarios for the 
Spacelab SLS-1 and IML-1 life sciences pre/post flight 
baseline data collection facility. These data collection ses- 
sions provide control data to compare against data collected 
on-orbit and measure post-mission readjustment to earth’s 
gravity. 

Another optimization tool using the Intelligent Per- 
turbation Algorithm has been developed to support work 
being done for the Space Station Program Support Contract 
for the scheduling of Space Station Design Reference Mis- 
sions (DRMs). Scheduling of DRMs involves generating 
demonstration timelines for Space Station crew and payload 
operations at selected periods during the I ifeti me of the Space 
Station. As shown in Figure 3, schedules have been gener- 
ated which show significant improvements over schedules 
produced with standard scheduling tools, both in terms of 
resource utilization and in the accomplishment of mission 
priorities . 8 The analysis of this DRM required the schedul- 
ing of 422 requested operations of 74 payloads over a two 
week period. Three resources were considered: crew, 

power, and the availability of a high quality microgravity 
environment. Assuming a rate of $100,000 per IVA crew- 
hour (as called out by NAS A in its recent request for propos- 
als for the Commercial Middeck Augmentation Module), 
the optimization analysis saved 5.3 million dollars per week 
in opportunity costs that would have otherwise been lost 
through inefficient scheduling. 
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Figure 3: DRM 4 Resource Utilization Optimization 


Industrial Space Facility Scheduling 
The ability to provide flexible manifesting and 
scheduling is critical to the operation of the Industrial Space 
Facility (1SF), a man- tended free-flying spaceplatform being 
developed by Space Industries for launch in the 1990s. The 
ISF has been designed to serve as a bridge to the Space 
Station era, providing a high-power, low-gravity environ- 
ment for conducting microgravity research. A software tool 
called the Prototype ISF Experiment Scheduler has demon- 
strated that efficient and cost-effective operation of the ISF 
is possible through the use of multi-variable optimization 
techniques based on the Intelligent Perturbation Algorithm 7 


Figure4 (next page) shows resource utilization profiles for an 
optimized 100 day ISF mission. The objective function was 
based largely on maximization of power utilization. 
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